agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedFrom: Álvaro Herrera <alvherre@kurilemu.de>
To: pgsql-committers@lists.postgresql.org
Subject: pgsql: Fix cascading standby reconnect failure after archive fallback
Date: Wed, 29 Jul 2026 15:17:03 +0000
Message-ID: <E1wp61n-00000000oMZ-1HoU@gemulon.postgresql.org> (raw)
Fix cascading standby reconnect failure after archive fallback
A cascading standby could fail to reconnect to its upstream standby with
"requested starting point ... is ahead of the WAL flush position" after
falling back to archive recovery. This happened because archive
recovery processes whole segment files, so after replaying a segment the
cascade's next read position lands at the start of the following
segment, which is ahead of the upstream's flush position reported by
GetStandbyFlushRecPtr() (still inside the just-replayed segment).
Fix by having the walreceiver check the upstream's current WAL flush
position via IDENTIFY_SYSTEM before issuing START_REPLICATION.
IDENTIFY_SYSTEM already returns this position (as xlogpos), but
walrcv_identify_system() previously discarded it; now we have a use for
it. If the requested start point exceeds the upstream's flush position
on the same timeline, the walreceiver waits for
wal_retrieve_retry_interval and retries.
The wait is limited to gaps of at most one WAL segment, which is the
expected case from the segment-granularity of archive recovery. Larger
gaps indicate the upstream is genuinely behind, so START_REPLICATION is
allowed to proceed (and fail) normally, letting the startup process fall
back to other WAL sources. The first wait is logged at LOG level;
subsequent waits are demoted to DEBUG1 to avoid log noise. The
walreceiver honors wal_receiver_timeout during the wait, so it will exit
if the upstream doesn't catch up in time.
To preserve ABI compatibility on back branches, the flush position from
IDENTIFY_SYSTEM is communicated via a new global variable
(WalRcvIdentifySystemLsn) rather than changing the signature of
walrcv_identify_system().
The bug was introduced in Postgres 9.3 by commit abfd192b1b5b, which
added a flush-position check in StartReplication() that rejects requests
ahead of the upstream server's WAL flush position.
Author: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>
Backpatch-through: 14
Discussion: https://postgr.es/m/CA+nrD2cTuTkkX5WXVZengTYYZbAO6zV8K+Tri-R0fbLFuoyMBA@mail.gmail.com
Branch
------
REL_18_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/33101632235ad064b2bd7bc04a5066048dc48023
Modified Files
--------------
.../libpqwalreceiver/libpqwalreceiver.c | 14 ++
src/backend/replication/walreceiver.c | 79 ++++++++++-
src/backend/utils/activity/wait_event_names.txt | 1 +
src/include/replication/walreceiver.h | 7 +
src/test/recovery/meson.build | 1 +
src/test/recovery/t/055_cascade_reconnect.pl | 148 +++++++++++++++++++++
6 files changed, 249 insertions(+), 1 deletion(-)
view thread (7+ messages)
Message-ID: <E1wp61n-00000000oMZ-1HoU@gemulon.postgresql.org>
Permalink: ../E1wp61n-00000000oMZ-1HoU@gemulon.postgresql.org/
Also on: postgresql.org/message-id/E1wp61n-00000000oMZ-1HoU@gemulon.postgresql.org
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: alvherre@kurilemu.de, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Fix cascading standby reconnect failure after archive fallback
In-Reply-To: <E1wp61n-00000000oMZ-1HoU@gemulon.postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox