Re: Exit walsender before confirming remote flush in logical replication
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andrey Silitskiy <a.silitskiy@postgrespro.ru>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Vitaly Davydov <v.davydov@postgrespro.ru>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com>, "sawada.mshk@gmail.com" <sawada.mshk@gmail.com>, "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>
Date: 2026-02-02T11:58:00Z
Lists: pgsql-hackers
On Mon, Feb 2, 2026 at 4:56 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Feb 02, 2026 at 02:52:36AM +0700, Andrey Silitskiy wrote:
> > +/*
> > + * Shutdown walsender in immediate mode.
> > + */
> > +static void
> > +WalSndDoneImmediate()
> > +{
> > + QueryCompletion qc;
> > +
> > + /* Try to inform receiver that XLOG streaming is done */
> > + SetQueryCompletion(&qc, CMDTAG_COPY, 0);
> > + EndCommand(&qc, DestRemote, false);
>
> Couldn't that be potentially dangerous, particularly if
> wal_sender_shutdown_mode is set to immediate, meaning that it applies
> to all the WAL senders? The WAL receiver side could be on a backend
> with an older backend version than the WAL sender where this new GUC
> exists. Hence, a completion could be understood incorrectly by a WAL
> receiver depending on how the receiving side is coded? Assuming this
> is merged into v19 in this shape, a receiver connecting to a newer
> server would get a new bevahior compared to older versions, without
> the receiver being aware of that.
>
> I suspect that this option, as designed, is potentially a footgun that
> could surprise many users, especially as it is super aggressive in
> shutting down everything on sight, unconditionally.
I’m not sure this is actually problematic when terminating a walsender in
immediate mode while the subscriber is running an older PostgreSQL version.
I haven't been able to come up with any failure scenario yet. However,
if this does turn out to be an issue, it might be better to use the alternative
approach I mentioned in [1].
With that approach, even in immediate mode the walsender simply receives
SIGTERM and exits. This is not new behavior for walsenders, so even when
the subscriber is on an older version, seems it shouldn't risk breaking
the shutdown behavior that such a subscriber is expecting.
Regards,
[1] https://postgr.es/m/CAHGQGwGotoS0VeMDdK6ezkhvdQpWZ5oJvO3QKJKEV6Pc+rZ_9A@mail.gmail.com
--
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 →
-
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