Re: Exit walsender before confirming remote flush in logical replication

Fujii Masao <masao.fujii@gmail.com>

From: Fujii Masao <masao.fujii@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Andrey Silitskiy <a.silitskiy@postgrespro.ru>, "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-09T07:47:23Z
Lists: pgsql-hackers
On Sat, Jan 3, 2026 at 9:32 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> 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.

Even with the proposed patch, this can already be done by setting
wal_sender_shutdown_mode in primary_conninfo for physical
replication, or in the CONNECTION clause of CREATE SUBSCRIPTION for
logical replication. For example:

    CREATE SUBSCRIPTION ... CONNECTION 'options=''-c
wal_sender_shutdown_mode=immediate''' ...

This allows wal_sender_shutdown_mode in postgresql.conf on the
primary or publisher to act as the default, while different values can
be specified per replication connection via primary_conninfo or the
CONNECTION clause. Thought?

Regards,

-- 
Fujii Masao



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Avoid blocking indefinitely while finishing walsender shutdown

  2. Add wal_sender_shutdown_timeout GUC to limit shutdown wait for replication

  3. pg_upgrade: Add --copy option

  4. Prevent possibility of panics during shutdown checkpoint.

  5. Support clean switchover.