On Tue, May 20, 2025 at 2:13 AM vignesh C <vignes...@gmail.com> wrote: > > On Tue, 20 May 2025 at 03:16, Michael Paquier <mich...@paquier.xyz> wrote: > > > > On Mon, May 19, 2025 at 11:19:48AM -0400, Robert Haas wrote: > > > The advantage of Fujii-san's proposal is that it is very simple to > > > implement. A subscription option would indeed be better, but it would > > > also be considerably more complex. Why not start simple and if someone > > > wants to do the work to add something more complicated, that is fine? > > > > Logically, adding that as an option of CREATE SUBSCRIPTION would just > > be a duplication of what a connection strings are already able to do > > with "options='-c foo=fooval'", isn't it?
I think there is a difference in the point that Vignesh made below; the worker can detect wal_receiver_timeout change and restart. > > > It seems to me that the issue of downgrading wal_receiver_timeout to > > become user-settable is if we're OK to allow non-superusers play with > > it in the code path where it's used currently. Knowing that physical > > WAL receivers are only spawned in a controlled manner by the startup > > process, this does not sound like an issue. > > If we set the wal_receiver_timeout configuration using ALTER ROLE for > the subscription owner's role, the apply worker will start with that > value. However, any changes made via ALTER ROLE ... SET > wal_receiver_timeout will not take effect for an already running apply > worker unless the subscription is disabled and re-enabled. In > contrast, this is handled automatically during CREATE SUBSCRIPTION, > where parameter changes are detected. Right. But given changing wal_receiver_timeout doesn't happen frequently in practice I guess this would not be a big downside of the proposed idea. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
