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-18T09:49:25Z
Lists: pgsql-hackers

Attachments

Here are the v4 patches implementing what I described above.

On top of Xuneng's v3 (keeping the wait_for_event and scoped log
window test improvements), the main changes are:

- The wait is now capped at one wal_segment_size.  If the gap is
  larger, we skip the wait and let START_REPLICATION fail normally
  so the startup process can fall back to archive.  This avoids
  indefinite polling when the upstream is fundamentally behind.

- The first "ahead of flush position" message is logged at LOG,
  subsequent ones at DEBUG1, to cut down on noise during a long wait.

Two patches attached: v4-0001 for master (extends the
walrcv_identify_system API with an optional server_lsn output
parameter) and v4-backpatch-0001 for stable branches (uses a global
variable to preserve ABI, per Alvaro's suggestion).

Both pass the new TAP test.

Best regards,
Marco

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.