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

On Tue, Mar 17, 2026 at 4:13 PM Marco Nenciarini
<marco(dot)nenciarini(at)enterprisedb(dot)com> 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