Re: BUG #18961: Race scenario where max_standby_streaming_delay is not honored - Mailing list pgsql-bugs

From Anthony Hsu
Subject Re: BUG #18961: Race scenario where max_standby_streaming_delay is not honored
Date
Msg-id CALQc50gU26NQsPRYjuBP5EN1HFPgrMcjxQ05hY=XEQDGHu_8Yg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18961: Race scenario where max_standby_streaming_delay is not honored  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-bugs

On Sun, Jun 29, 2025 at 8:28 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Sun, Jun 29, 2025 at 5:07 AM Anthony Hsu <erwaman@gmail.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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL 18 beta1 - Segmentation fault on custom type casting
Next
From: Fujii Masao
Date:
Subject: Re: Unexpected behavior when setting "idle_replication_slot_timeout"