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

Hi shihao,

On Fri, Oct 2, 2026 at 1:38 PM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Hi,
>
> I reviewed v2. The bug is real on master and v2 fixes it. With
> Dmytro's steps, master never cancels the cursor session. With v2 it
> gets FATAL about one second after it takes the pin.
>
> I had a few small comments, so I just made the changes. v3 is
> attached.
>
> - It calls WaitLatch directly in standby.c, so proc.c and proc.h are
> not touched. That should be easier to backpatch.
> - The comment no longer names PROCSIG_RECOVERY_CONFLICT_BUFFERPIN,
> which is gone since 17f51ea8187.
> - The 1s is a define now, and the commit message is shorter.
>
> The patch in [1] rewrites the same wait as a loop, so the two do not
> apply together. Its expired path still sleeps with no timeout, so
> this fix is still needed after it.
>
> [1] https://www.postgresql.org/message-id/flat/44c24dcf-5710-410f-b1b6-d10b315f3d51(at)postgrespro(dot)ru

Thanks for pointing me here. I've been hovering for this for a while.

The diganose of the problem seems good to me. The fix is small and
helps to mitigate the stall. What I'm a bit conservative of is the
polling and its repeated broadcasts. A more ideal fix seems to be more
event-driven -- let the late pinners cancel themselves. I'ven't
thought about it carefully. That's certainly more complex and might
involve more trade-offs making the idea not pursuable. That being
said, the polling itself might not be concerning because we wait for
1s to do a deadlock check before max_standby_*_delay is expired if
it's set. However, it seems to violate the promise of
max_standby_*_delay to some extent -- the startup could be stalled
further even if it has already expired.

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.