Horton
Menu

Re: BUG: Cascading standby fails to reconnect after falling back to archive recovery

Marco Nenciarini <marco.nenciarini@enterprisedb.com>

View thread
From: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
To: Xuneng Zhou <xunengzhou@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, pgsql-hackers@postgresql.org
Date: 2026-03-16T21:49:44Z
Lists: pgsql-hackers

Attachments

Attached is a v2 patch that implements the "handshake clamp" approach
Xuneng suggested.  Rather than tracking lastStreamedFlush in
process-local state (which doesn't survive a cascade restart, as
Fujii-san demonstrated), it uses the WAL flush position already
returned by IDENTIFY_SYSTEM.

The walreceiver now checks the upstream's flush position before issuing
START_REPLICATION.  If the requested startpoint is ahead (on the same
timeline), it waits for wal_retrieve_retry_interval and retries.  This
works across restarts since it queries the upstream's live position on
every connection attempt, and requires no new state variables.

When timelines differ, we let START_REPLICATION handle the timeline
negotiation as before.

The patch includes a TAP test (053_cascade_reconnect.pl) that
reproduces the scenario and verifies the fix.

Commits

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

  1. Fix scenario where streaming standby gets stuck at a continuation record.

  2. Allow a streaming replication standby to follow a timeline switch.