Re: Set 1s WaitLatch timeout if standby limit has expired in ResolveRecoveryConflictWithBufferPin

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/