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-20T12:40:42Z
Lists: pgsql-hackers 
On Fri, Mar 20, 2026 at 4:33 AM Xuneng Zhou <xunengzhou@gmail.com> wrote:
>
> After taking a closer look, I'm less certain about this. I'll
> investigate further. Could you also explain why you think this is the
> case?

The mechanism is in RequestXLogStreaming (walreceiverfuncs.c, around
line 276): it explicitly truncates recptr to the segment start before
passing it to the walreceiver.  So even when both nodes have replayed
the same records, the cascade's startpoint lands at the beginning of
the next segment while the upstream's GetStandbyFlushRecPtr returns
replayPtr somewhere inside the current one.

I covered this in more detail in my reply to your previous message.

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.