On 2 Oct 2026, Shihao Zhong wrote: > It calls WaitLatch directly in standby.c, so proc.c and proc.h are > not touched. That should be easier to backpatch.
We hit what looks like this bug today on a production standby running our PostgreSQL 17.11 build. Both max_standby_*_delay settings were 30s, but replay lag had already reached 5h41m. During investigation, startup was waiting in BufferPin at an unchanged LSN. Following Dmytro's tip, pg_log_backend_memory_contexts() woke it up. A buffer-pin recovery conflict was logged, and the standby caught up without a restart. I tested v3 on REL_17_STABLE, adapting the signal and wait-event enum names. I used two cursors and SIGSTOP/SIGCONT on the first reader so that the second pin was acquired after the cancellation broadcast. Without the fix, the second reader survived cancellation of the first, and replay needed the diagnostic wakeup. With v3, the second reader was canceled in about a second, without an external wakeup. I'll reopen the CF entry [0]. Please let me know if that's unnecessary because this bug is already tracked elsewhere. Thank you! Best regards, Andrey Borodin. [0] https://commitfest.postgresql.org/patch/6445/
