Re: Make wal_receiver_timeout configurable per subscription

On Tue, May 20, 2025 at 2:13 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Tue, 20 May 2025 at 03:16, Michael Paquier <michael(at)paquier(dot)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