Re: BUG: Cascading standby fails to reconnect after falling back to archive recovery
Xuneng Zhou <xunengzhou@gmail.com>
From: Xuneng Zhou <xunengzhou@gmail.com>
To: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, pgsql-hackers@postgresql.org
Date: 2026-03-17T12:13:36Z
Lists: pgsql-hackers
Attachments
- v3-backpatch-0001-Fix-cascading-standby-reconnect-failure-after-arc.patch (application/octet-stream) patch v3-0001
On Tue, Mar 17, 2026 at 5:31 PM Marco Nenciarini <marco.nenciarini@enterprisedb.com> wrote: > > Since this bug dates back to 9.3, the fix will likely need backpatching. > The v2 patch changes the walrcv_identify_system() signature, which would > be an ABI break on stable branches (walrcv_identify_system_fn is a > function pointer in the WalReceiverFunctionsType struct). > > Attached is a backpatch-compatible variant that avoids the API change. > Instead of adding a parameter, libpqrcv_identify_system() stores the > flush position in a new global variable (WalRcvIdentifySystemLsn), and > the walreceiver reads it directly. The fix logic and TAP test are > otherwise identical. > > For master I'd still prefer the v2 approach with the extended signature, > since it's cleaner and there's no ABI constraint. > > Best regards, > Marco I think that the ABI concern for backpatching is valid, and the proposed workaround looks reasonable to me. Resetting WalRcvIdentifySystemLsn before walrcv_identify_system() seems like a sensible defensive move, so I’ve added it into v3. The TAP test has also been updated as well. -- Best, Xuneng
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix scenario where streaming standby gets stuck at a continuation record.
- 066871980183 11.0 cited
-
Allow a streaming replication standby to follow a timeline switch.
- abfd192b1b5b 9.3.0 cited