Re: Make wal_receiver_timeout configurable per subscription

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?

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.

How about logical WAL receivers, though? These are spawned by
pgoutput, but allowing wal_receiver_timeout could allow one to load
the value they want in a non-superuser context, especially in the
context of function calls (for example in the context of an index,
constraint validation, etc.). So it seems to me that the real
question is deciding if we'd be OK with that. I think that we're
actually OK here because this GUC is only used in the main apply
loops, where the GUC should be reset to its original value once we're
done applying a single logical change.
--
Michael