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

On Tue, Mar 17, 2026 at 8:20 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
>
> On Tue, Mar 17, 2026 at 7:56 PM Marco Nenciarini
> <marco(dot)nenciarini(at)enterprisedb(dot)com> wrote:
> >
> > Thanks for verifying the fix and improving the test, Xuneng.
> >
> > The wait_for_event() synchronization is a nice addition — it gives
> > deterministic proof that the walreceiver actually entered the
> > upstream-catchup path. The scoped log window with slurp_file() is
> > also cleaner than the broad log_contains() I had before.
> >

After thinking about this more, I’m less satisfied and convinced with
polling at wal_retrieve_retry_interval. If the upstream stalls for a
long time, or permanently, the walreceiver can loop indefinitely,
leaving startup effectively pinned in the streaming path instead of
switching to other WAL sources. In that case, repeated “ahead of flush
position” log entries can also become noisy. On the other hand, if the
upstream catches up quickly, walreceiver still won’t notice until the
next interval, adding unnecessary latency of up to one full
wal_retrieve_retry_interval.

--
Best,
Xuneng