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-21T10:52:28Z
Lists: pgsql-hackers

Attachments

Here are the v6 patches.

Xuneng correctly pointed out that RequestXLogStreaming rounds down,
not up, so it isn't the cause of the gap.  The actual mechanism is
that archive recovery processes whole segment files: after both nodes
replay the same archived segment N, the cascade's next read position
lands at the start of segment N+1, while the upstream's
GetStandbyFlushRecPtr returns replayPtr inside segment N.

Changes from v5:

- Updated the code comment and commit message to describe the correct
  root cause (archive recovery segment granularity, not
  RequestXLogStreaming truncation).

- Reset the catchup state when the upstream is no longer behind.
  Without this, if the walreceiver successfully streams, the
  connection breaks, and it loops back to find itself ahead again,
  the stale deadline from the previous wait would cause an immediate
  timeout.

Two patches attached: v6-0001 for master (extends the
walrcv_identify_system API) and v6-backpatch-0001 for stable branches
(global variable to preserve ABI).

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.