Hi, Alexander! Thanks for your comments!
On Jan 3, 2026 at 2:32 AM Alexander Korotkov
<aekorotkov(at)gmail(dot)com> wrote:
> I think it is reasonable to move control over the walsender
> shutdown behavior to the primary server. I see an analogy with
> synchronous_commit and synchronous_standby_names. Primary decides
> which standbys wait and which way to wait for them. Similarly,
> the primary should decide who to wait on the shutdown.
With the current patch, the walsender process termination mode is set
on the primary server using a GUC variable, and clients who do not want
to wait for a data flush to any of the replicas can configure this
parameter for specific replicas (wal_sender_timeout is currently working
in a similar way, which was also discussed in the thread [1]).
> I propose to rename GUC to default_wal_sender_shutdown_mode.
> Also, given we would more likely need to wait for a flush during
> streaming replication, I would suggest following modes: immediate,
> wait_for_flush_streaming_only, wait_for_flush. The new intermediate
> option would make walsender wait for a flush only for physical
> standbys but not for logical subscribers.
Currently, in this patch, it is also possible to configure the server
so that it waits only for physical replicas. The administrator is given
the opportunity to flexibly change the default wait_flush mode for each
replica individually. In this case, you do not need to add this feature
inside modes of the proposed GUC default_wal_sender_shutdown_mode, but
you can save place for a potential semantically new mode besides wait_flush
and immediate (for example, waiting for the flush only for a certain period
of time, and then terminating the process).
[1]:
https://www.postgresql.org/message-id/flat/0A3221C70F24FB45833433255569204D1FAAD3AE%40G01JPEXMBYT05
