Hi Stepan, On 17 Aug 2026, Stepan Tyagushev wrote: > The discussion in that thread ultimately led to patch [2]; note the > added > check in src/backend/access/transam/xlogrecovery.c. > > Previously we'd unconditionally kill the walreceiver in the > XLOG_FROM_STREAM handler; now we check whether it's actually > streaming, > and > if it's in WALRCV_WAITING state we leave it alone.
Thank you for pointing this out. The production cluster was running the current minor release at the time of the report. In any case, I rechecked the test on a tree that already contains 17b2d5ec759, and there is still a smaller window. After walrcv_endstreaming() returns and while WalRcvFetchTimeLineHistoryFiles() runs, the shared state is still WALRCV_STREAMING. WALRCV_WAITING is set only later by WalRcvWaitForStartPosition(). If startup wakes in that interval, the check added by 17b2d5ec759 still calls XLogShutdownWalRcv(). I also checked the negative direction of test 054. I kept its deterministic WakeupRecovery() and injection point, but removed WALRCV_SWITCHING_TIMELINE. Startup then enters XLogShutdownWalRcv() and waits for the walreceiver to exit instead of reaching RecoveryRetrieveRetryInterval. The test fails as expected. With the new state it passes. So failure to reproduce this without the injection point seems to be a matter of the window being short. No need to manually reproduce the problem, it is simulated in the test. And test is failing if we do not apply the fix. > Since we already have a general WALRCV_WAITING state, why do we need > to > introduce another specific state just to clarify what exactly we are > waiting for? WALRCV_WAITING means that walreceiver is ready for new instructions. That is not yet true while it is fetching the history file, so setting WAITING earlier would allow startup to request another stream before the fetch finishes. The separate state distinguishes those two conditions. Nevertheless, this is independent from the main problem in this thread: XLogFileReadAnyTLI applying a divergent segment from an older timeline. The extra walreceiver restart is much less serious, and the additional state deserves its own discussion. Maybe I should move patches 0002/0003 to a separate thread and keep the next version here focused on 0001. I also saw Surya's review of 0001. The comments about the conservative switch-point behavior, diagnostics, and positive test coverage are valuable, and I agree with them. I am not ready to post a v3 addressing them yet, but I hope to do that soon. Thank you! Best regards, Andrey Borodin.
