Re: Exit walsender before confirming remote flush in logical replication
| От | Michael Paquier |
|---|---|
| Тема | Re: Exit walsender before confirming remote flush in logical replication |
| Дата | |
| Msg-id | aYBYj_RaGxFoHdXz@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Exit walsender before confirming remote flush in logical replication (Andrey Silitskiy <a.silitskiy@postgrespro.ru>) |
| Ответы |
Re: Exit walsender before confirming remote flush in logical replication
Re: Exit walsender before confirming remote flush in logical replication |
| Список | 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
Вложения
В списке pgsql-hackers по дате отправления: