On Thu, Nov 20, 2025 at 4:05 PM Andrey Silitskiy <[email protected]> wrote: > > On Wed, Nov 19, 2025 at 8:46 PM Fujii Masao > <masao(dot)fujii(at)gmail(dot)com> wrote: > > How about using PGC_USERSET instead of PGC_SIGHUP, similar to > > wal_sender_timeout? > > Dear Fujii, thanks for the review! > > Current version of the patch suggests changing the shutdown mode of > logical senders globally for the server. As I wrote above: patch > excludes receiver's side decision whether the sender is allowed to hang > on shutdown. In addition, it provides simpler administration of a system.
Even with PGC_USERSET instead of PGC_SIGHUP, we can still control the shutdown mode globally by setting it in postgresql.conf. The difference is that PGC_USERSET also allows per–replication-user overrides when needed, which gives users more flexibility without losing the ability to set a server-wide setting, I think. > As discussed earlier, physical replication is more sensitive to data > divergence and there is no problem with apply_worker and backend lock > conflict, which makes the use-case more narrow. I think there are valid use cases for applying this setting to physical replication as well. For example, please consider a system that has generated a large amount of WAL due to bulk loading, and a remote standby with a slow or low-bandwidth network link. In such a case, some would think an immediate shutdown could be desirable rather than waiting a long time for all outstanding WAL to be sent. Of course, misconfiguring this parameter for physical replication could lead to serious issues. So if we decide to apply it to physical walsenders, the docs might need to clearly explain the risks so that users can make informed decisions, like we've already done for other parameters like fsync, full_page_writes, etc. Regards, -- Fujii Masao
