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

From: Marco Nenciarini <marco(dot)nenciarini(at)enterprisedb(dot)com>
To: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BUG: Cascading standby fails to reconnect after falling back to archive recovery
Date: 2026-03-20 12:40:42
Message-ID: CA+nrD2d46mxqu1zEyAfKEj+pwO50nkYRL+3NLzGGvv76tQyOYQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 20, 2026 at 4:33 AM Xuneng Zhou <xunengzhou(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2026-03-20 12:41:55 Re: Emitting JSON to file using COPY TO
Previous Message Mihail Nikalayeu 2026-03-20 12:35:00 Re: Adding REPACK [concurrently]