Re: Exit walsender before confirming remote flush in logical replication
Alexander Korotkov <aekorotkov@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Andrey Silitskiy <a.silitskiy@postgrespro.ru>
Cc: Fujii Masao <masao.fujii@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "sawada.mshk@gmail.com" <sawada.mshk@gmail.com>,
"michael@paquier.xyz" <michael@paquier.xyz>, "peter.eisentraut@enterprisedb.com" <peter.eisentraut@enterprisedb.com>, "dilipbalaut@gmail.com" <dilipbalaut@gmail.com>,
"andres@anarazel.de" <andres@anarazel.de>, "amit.kapila16@gmail.com" <amit.kapila16@gmail.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Peter Smith <smithpb2250@gmail.com>,
Greg Sabino Mullane <htamfids@gmail.com>, Vitaly Davydov <v.davydov@postgrespro.ru>
Date: 2026-01-03T00:31:51Z
Lists: pgsql-hackers
Hi, Andrey! On Thu, Nov 27, 2025 at 12:19 PM Andrey Silitskiy <a.silitskiy@postgrespro.ru> wrote: > On Nov 23, 2025 at 11:46 PM Fujii Masao > <masao(dot)fujii(at)gmail(dot)com> wrote: > > 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. > > ... > > I think there are valid use cases for applying this setting to > > physical replication as well. > Thanks for the comments. I agree, this parameter also seems usable > for physical replication, if you use it with caution. In this case, > it really becomes useful to be able to configure a parameter for > each connection. I have added these changes to my patch. > > Also, earlier I did not mention another difference between my patch > and those discussed earlier. Previously, even in immediate mode, > WalSndCaughtUp flag was checked before calling WalSndDone, > and this made it impossible to shut down even in immediate mode > with WalSndCaughtUp = false when the server has full output buffers. > This does not happen in the current patch implementation. I added > an additional test case for this situation. Thank you for reviving this thread. 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. I would like to make a couple of suggestions for the patch. 1) I think it's useful to tune particular standbys/subscribers to specify the walsender shutdown mode. It was possible in the patch by Hayato Kuroda, and it would be a pity to lose. I suggest implementing the walsender shutdown mode as a replication slot option. 2) Given that walsender shutdown mode would be a replication slot option, 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. What do you think? ------ Regards, Alexander Korotkov Supabase
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Avoid blocking indefinitely while finishing walsender shutdown
- c0b24b32b0d3 19 (unreleased) landed
-
Add wal_sender_shutdown_timeout GUC to limit shutdown wait for replication
- a8f45dee9176 19 (unreleased) landed
-
pg_upgrade: Add --copy option
- 746915c68669 16.0 cited
-
Prevent possibility of panics during shutdown checkpoint.
- c6c333436491 10.0 cited
-
Support clean switchover.
- 985bd7d49726 9.4.0 cited