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

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Marco Nenciarini <marco(dot)nenciarini(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: BUG: Cascading standby fails to reconnect after falling back to archive recovery
Date: 2026-01-29 11:33:11
Message-ID: CAHGQGwE9BZ81vSnnCo74pOopHSwxF0G_66r6=GtfX81DRWr2Zg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 29, 2026 at 2:03 AM Marco Nenciarini
<marco(dot)nenciarini(at)enterprisedb(dot)com> wrote:
>
> Hi hackers,
>
> I've encountered a bug in PostgreSQL's streaming replication where cascading
> standbys fail to reconnect after falling back to archive recovery. The issue
> occurs when the upstream standby uses archive-only recovery.
>
> The standby requests streaming from the wrong WAL position (next segment boundary
> instead of the current position), causing connection failures with this error:
>
> ERROR: requested starting point 0/A000000 is ahead of the WAL flush
> position of this server 0/9000000

Thanks for the report!
I was also able to reproduce this issue on the master branch.

Interestingly, I couldn't reproduce it on v11 using the same test case.
This makes me wonder whether the issue was introduced in v12 or later.

Do you see the same behavior in your environment?

Regards,

--
Fujii Masao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ahmed Et-tanany 2026-01-29 11:33:28 Re: [PATCH] Add max_logical_replication_slots GUC
Previous Message John Naylor 2026-01-29 11:31:53 Re: refactor architecture-specific popcount code