Re: Exit walsender before confirming remote flush in logical replication

On Thu, Nov 20, 2025 at 4:05 PM Andrey Silitskiy
<a(dot)silitskiy(at)postgrespro(dot)ru> 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