Re: BUG #18961: Race scenario where max_standby_streaming_delay is not honored

Simplified my patch and posted it on pgsql-hackers here:
https://www.postgresql.org/message-id/flat/CALQc50gi-Kw9m1r6hytf12473-fCECy%3Dq9JtKS4ANeJFEyCBTw%40mail.gmail.com

On Sun, Jun 29, 2025 at 8:28 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:

> On Sun, Jun 29, 2025 at 5:07 AM Anthony Hsu <erwaman(at)gmail(dot)com> wrote:
> >
> > Made a few changes to my patch and attached a new version. Changes
> include:
> >
> > * avoid sending PROCSIG_RECOVERY_CONFLICT_BUFFERPIN in a tight loop
> after standby limit is reached by adding a small sleep after each send,
> starting at 1ms and doubling each time up to 1s (similar to what's done in
> WaitExceedsMaxStandbyDelay here [1]). Sleep time is reset in
> LockBufferForCleanup once cleanup lock is successfully acquired
> > * don't set deadlock timeout once standby limit has passed since after
> that, the standby timeout will fire immediately, so no need to set deadlock
> timeout as well
> >
> > Let me know if you have any thoughts or comments. I am thinking of
> sending it to pgsql-hackers soon.
>
> I haven't got time to look into your new patch, feel free to start a
> thread in pgsql-hackers, I can review it there once I get time,
> thanks.
>
>
> --
> Regards,
> Dilip Kumar
> Google
>