Horton
Menu

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

Dilip Kumar <dilipbalaut@gmail.com>

View thread
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Anthony Hsu <erwaman@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2025-06-30T03:28:33Z
Lists: pgsql-bugs 
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Message style improvements

  2. Correct list of files in src/backend/lib/README

  3. Fix re-distributing previously distributed invalidation messages during logical decoding.