Horton
Menu

Re: Exit walsender before confirming remote flush in logical replication

Ronan Dunklau <ronan@dunklau.fr>

View thread
From: Ronan Dunklau <ronan@dunklau.fr>
To: Andrey Silitskiy <a.silitskiy@postgrespro.ru>
Cc: Vitaly Davydov <v.davydov@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>, Alexander Korotkov <aekorotkov@gmail.com>, Fujii Masao <masao.fujii@gmail.com>
Date: 2026-02-10T09:15:51Z
Lists: pgsql-hackers 
Le mercredi 28 janvier 2026 à 12:33, Andrey Silitskiy <a.silitskiy@postgrespro.ru> a écrit :
> This is also possible in the current implementation, but your option offers
> a simpler interface if we do not plan to add new wallsender completion
> modes.
> The naming of the parameter is also a question, because wal_sender_timeout
> already exists (which also fits the name wal_sender_stop_timeout quite
> well).
> The difference between these parameters may not be obvious to users.
> Thoughts?

The naming can probably be revisited but the use case I have in mind
is the following:

- we want to bound the time it takes to perform a restart, or a stop, with walsenders setup.
- the immediate shutdown solves this problem
- however, if one were to stop the service before doing a pg_upgrade, they would
have no other choice than either disable the behaviour entirely (by switching to
wait_flush) or fail the upgrade if a logical replication slot is pending
changes. Switching to wait_flush may be acceptable in that case, but then if the walreceiver
does not catch up in time we're back to agressively stopping postgres to abort
the waiting stop process, and the upgrade entirely.

So in my mind having a timeout makes a lot more sense.

What do you think ?

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.