On Tue, Mar 17, 2026 at 4:13 PM Marco Nenciarini <[email protected]> wrote: > > I agree, a standalone test file is the right call here. > > I looked at the same candidates. 025_stuck_on_old_timeline.pl is the > closest thematic match, but its archive command intentionally copies > only history files and the whole test revolves around promotion and > timeline following. Adapting it would mean replacing the archive > command and skipping the promotion, which defeats its original purpose. > > The reconnect-after-archive-fallback scenario is distinct enough to > justify its own file, and at 143 lines it's reasonably small. > > Best regards, > Marco
I’ve applied the patch and verified the fix using the two scripts you provided earlier, as well as the failing test from v1 provided by Fujii-san. I’ve also made some small improvements to the TAP test: 1) Added a positive synchronization point using wait_for_event() on walreceiver / WalReceiverUpstreamCatchup, so the test now proves it enters the reconnect-behind-upstream window before asserting outcomes. 2) Replaced broad log scanning with a scoped log window: - capture logfile offset after rotation - use slurp_file(..., $offset) for post-restart assertions only - assert absence of the old “requested starting point … ahead of the WAL flush position” error in that bounded window. Please check it. -- Best, Xuneng
v3-0001-Fix-cascading-standby-reconnect-failure-after-arc.patch
Description: Binary data
