Horton

Re: Exit walsender before confirming remote flush in logical replication

Andrey Silitskiy <a.silitskiy@postgrespro.ru>

View thread
From: Andrey Silitskiy <a.silitskiy@postgrespro.ru>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: "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: 2025-11-20T07:05:05Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add wal_sender_shutdown_timeout GUC to limit shutdown wait for replication

  2. pg_upgrade: Add --copy option

  3. Prevent possibility of panics during shutdown checkpoint.

  4. Support clean switchover.

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.
But I'm ready to hear other opinions on this matter.

 > Shouldn't physical replication walsenders also honor this parameter?
 > For example, the immediate mode seems useful for physical walsenders 
connected
 > from a very remote standby (e.g., DR site). Thought?

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.

By the way, does anyone find the name of IMMEDIATE mode too similar to
the "pg_ctl stop" mode and a little confusing? Initially, I planned
to call this mode WALSND_SHUTDOWN_MODE_FORCED instead of
WALSND_SHUTDOWN_MODE_IMMEDIATE.

Best Regards,
Andrey Silitskiy