Re: Exit walsender before confirming remote flush in logical replication - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Exit walsender before confirming remote flush in logical replication
Date
Msg-id aYBYj_RaGxFoHdXz@paquier.xyz
Whole thread Raw
In response to Re: Exit walsender before confirming remote flush in logical replication  (Andrey Silitskiy <a.silitskiy@postgrespro.ru>)
Responses Re: Exit walsender before confirming remote flush in logical replication
Re: Exit walsender before confirming remote flush in logical replication
List pgsql-hackers
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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: walsender: Assert MyReplicationSlot is set before use
Next
From: Corey Huinker
Date:
Subject: Re: Add expressions to pg_restore_extended_stats()