| 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
| 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 |