On Tue, Mar 17, 2026 at 8:20 PM Xuneng Zhou <[email protected]> wrote: > > On Tue, Mar 17, 2026 at 7:56 PM Marco Nenciarini > <[email protected]> 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
