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
signature.asc
Description: PGP signature
