Horton
Menu

Thread

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.

  1. BUG #18961: Race scenario where max_standby_streaming_delay is not honored

    PG Bug reporting form <noreply@postgresql.org> — 2025-06-19T00:27:27Z

    The following bug has been logged on the website:

Bug reference:      18961
Logged by:          Anthony Hsu
Email address:      erwaman@gmail.com
PostgreSQL version: 17.5
Operating system:   Linux
Description:        

In the current ResolveRecoveryConflictWithBufferPin implementation in
standby.c, I think there's a race scenario where a backend holding a
conflicting buffer pin won't receive a PROCSIG_RECOVERY_CONFLICT_BUFFERPIN
message promptly:
1. Assume max_standby_streaming_delay has expired when the startup process
enters ResolveRecoveryConflictWithBufferPin
2. Assume backend 1 holds a conflicting buffer pin while backend 2 does not
3. Since we are past the standby limit time, the startup process broadcasts
PROCSIG_RECOVERY_CONFLICT_BUFFERPIN here [1] without enabling any timeouts
4. Then the startup process waits to be woken up via
ProcWaitForSignal(WAIT_EVENT_BUFFER_PIN) here [2]
5. Suppose backend 2 receives PROCSIG_RECOVERY_CONFLICT_BUFFERPIN first,
sees it does not hold a conflicting buffer pin, and *then* proceeds to pin
the buffer
6. Suppose then backend 1 receives PROCSIG_RECOVERY_CONFLICT_BUFFERPIN,
processes interrupts, and cancels itself. During cleanup, in UnpinBuffer(),
it will see the pin count is still > 1 (startup process + backend 2 have it
pinned), so it will NOT wake up the startup process.
7. The startup process will only get woken up once backend 2 unpins the
buffer and the pin count reaches 1 (or some other signal causes the startup
process's latch to be set). Only then will it try to acquire the cleanup
lock again and broadcast another PROCSIG_RECOVERY_CONFLICT_BUFFERPIN message
if it fails to acquire the cleanup lock.
The unexpected behavior is in step (7), where it could be arbitrarily long
until the startup process is woken up again. The expected behavior is that
since max_standby_streaming_delay has already expired, the startup process
should wake up quickly and broadcast another
PROCSIG_RECOVERY_CONFLICT_BUFFERPIN message if there are still conflicting
backends.
I was able to reproduce this scenario with some custom code to control the
execution sequence.
One way to fix this scenario is to just remove the `if` block here [3]
entirely so that we always enable the STANDBY_TIMEOUT and
STANDBY_DEADLOCK_TIMEOUT timeouts.
[1]
https://github.com/postgres/postgres/blob/45c357e0e85d2dffe7af5440806150124a725a01/src/backend/storage/ipc/standby.c#L805
[2]
https://github.com/postgres/postgres/blob/45c357e0e85d2dffe7af5440806150124a725a01/src/backend/storage/ipc/standby.c#L842
[3]
https://github.com/postgres/postgres/blob/45c357e0e85d2dffe7af5440806150124a725a01/src/backend/storage/ipc/standby.c#L800-L806

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

    Dilip Kumar <dilipbalaut@gmail.com> — 2025-06-19T15:17:47Z

    On Thu, Jun 19, 2025 at 5:25 PM PG Bug reporting form
<noreply@postgresql.org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference:      18961
> Logged by:          Anthony Hsu
> Email address:      erwaman@gmail.com
> PostgreSQL version: 17.5
> Operating system:   Linux
> Description:
>
> In the current ResolveRecoveryConflictWithBufferPin implementation in
> standby.c, I think there's a race scenario where a backend holding a
> conflicting buffer pin won't receive a PROCSIG_RECOVERY_CONFLICT_BUFFERPIN
> message promptly:
> 1. Assume max_standby_streaming_delay has expired when the startup process
> enters ResolveRecoveryConflictWithBufferPin
> 2. Assume backend 1 holds a conflicting buffer pin while backend 2 does not
> 3. Since we are past the standby limit time, the startup process broadcasts
> PROCSIG_RECOVERY_CONFLICT_BUFFERPIN here [1] without enabling any timeouts
> 4. Then the startup process waits to be woken up via
> ProcWaitForSignal(WAIT_EVENT_BUFFER_PIN) here [2]
> 5. Suppose backend 2 receives PROCSIG_RECOVERY_CONFLICT_BUFFERPIN first,
> sees it does not hold a conflicting buffer pin, and *then* proceeds to pin
> the buffer
> 6. Suppose then backend 1 receives PROCSIG_RECOVERY_CONFLICT_BUFFERPIN,
> processes interrupts, and cancels itself. During cleanup, in UnpinBuffer(),
> it will see the pin count is still > 1 (startup process + backend 2 have it
> pinned), so it will NOT wake up the startup process.
> 7. The startup process will only get woken up once backend 2 unpins the
> buffer and the pin count reaches 1 (or some other signal causes the startup
> process's latch to be set). Only then will it try to acquire the cleanup
> lock again and broadcast another PROCSIG_RECOVERY_CONFLICT_BUFFERPIN message
> if it fails to acquire the cleanup lock.
> The unexpected behavior is in step (7), where it could be arbitrarily long
> until the startup process is woken up again. The expected behavior is that
> since max_standby_streaming_delay has already expired, the startup process
> should wake up quickly and broadcast another
> PROCSIG_RECOVERY_CONFLICT_BUFFERPIN message if there are still conflicting
> backends.
> I was able to reproduce this scenario with some custom code to control the
> execution sequence.
> One way to fix this scenario is to just remove the `if` block here [3]
> entirely so that we always enable the STANDBY_TIMEOUT and
> STANDBY_DEADLOCK_TIMEOUT timeouts.
> [1]
> https://github.com/postgres/postgres/blob/45c357e0e85d2dffe7af5440806150124a725a01/src/backend/storage/ipc/standby.c#L805
> [2]
> https://github.com/postgres/postgres/blob/45c357e0e85d2dffe7af5440806150124a725a01/src/backend/storage/ipc/standby.c#L842
> [3]
> https://github.com/postgres/postgres/blob/45c357e0e85d2dffe7af5440806150124a725a01/src/backend/storage/ipc/standby.c#L800-L806

I agree this looks like a race condition, but I am not sure about the
proposed solution. ResolveRecoveryConflictWithBufferPin() is called by
LockBufferForCleanup() to wait for a process currently holding a
buffer pin. However, new processes can still acquire the pin.. So I
think the problem lies in the logic of the wakeup mechanism of the
UnpinBuffer() no? The intended behavior is for the startup process to
be woken regardless of Backend 2 subsequently acquiring the pin, but
the current tracking mechanism is insufficient.

-- 
Regards,
Dilip Kumar
Google

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

    Anthony Hsu <erwaman@gmail.com> — 2025-06-19T15:58:16Z

    Yes, another option might be to change the wakeup logic so that the startup
process is still woken up even if new processes have acquired the pin. The
main thing is the startup process should be woken up promptly so that it
can recheck if it can acquire the cleanup lock and if not,
send PROCSIG_RECOVERY_CONFLICT_BUFFERPIN again to cancel any new backends.

Before the standby limit time (default 30s) is reached,
ResolveRecoveryConflictWithBufferPin will enable both a standby limit
timeout and a deadlock timeout (default 1s). So if someone is holding a
conflicting buffer pin for a long time, due to the deadlock timeout, the
startup process will get woken up every 1s and recheck until we reach the
standby limit, at which point it'll send the
PROCSIG_RECOVERY_CONFLICT_BUFFERPIN. But after reaching standby limit, the
next time the startup process does ResolveRecoveryConflictWithBufferPin, it
only sends PROCSIG_RECOVERY_CONFLICT_BUFFERPIN without enabling the
timeouts, which leads to the possibility of this race. So I thought a
simple solution to address this race would be to just always enable the
timeouts.

For context, the reason I noticed this issue and am interested in getting
it fixed is that I have seen cases where the startup process gets stalled
for minutes and sometimes hours due to conflicting buffer pins, leading to
high replay lag, even though the standby limit has not been changed (still
the default 30s). My expectation is that once the standby limit has
expired, conflicting backends should be promptly canceled.

On Thu, Jun 19, 2025 at 8:18 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:

> On Thu, Jun 19, 2025 at 5:25 PM PG Bug reporting form
> <noreply@postgresql.org> wrote:
> >
> > The following bug has been logged on the website:
> >
> > Bug reference:      18961
> > Logged by:          Anthony Hsu
> > Email address:      erwaman@gmail.com
> > PostgreSQL version: 17.5
> > Operating system:   Linux
> > Description:
> >
> > In the current ResolveRecoveryConflictWithBufferPin implementation in
> > standby.c, I think there's a race scenario where a backend holding a
> > conflicting buffer pin won't receive a
> PROCSIG_RECOVERY_CONFLICT_BUFFERPIN
> > message promptly:
> > 1. Assume max_standby_streaming_delay has expired when the startup
> process
> > enters ResolveRecoveryConflictWithBufferPin
> > 2. Assume backend 1 holds a conflicting buffer pin while backend 2 does
> not
> > 3. Since we are past the standby limit time, the startup process
> broadcasts
> > PROCSIG_RECOVERY_CONFLICT_BUFFERPIN here [1] without enabling any
> timeouts
> > 4. Then the startup process waits to be woken up via
> > ProcWaitForSignal(WAIT_EVENT_BUFFER_PIN) here [2]
> > 5. Suppose backend 2 receives PROCSIG_RECOVERY_CONFLICT_BUFFERPIN first,
> > sees it does not hold a conflicting buffer pin, and *then* proceeds to
> pin
> > the buffer
> > 6. Suppose then backend 1 receives PROCSIG_RECOVERY_CONFLICT_BUFFERPIN,
> > processes interrupts, and cancels itself. During cleanup, in
> UnpinBuffer(),
> > it will see the pin count is still > 1 (startup process + backend 2 have
> it
> > pinned), so it will NOT wake up the startup process.
> > 7. The startup process will only get woken up once backend 2 unpins the
> > buffer and the pin count reaches 1 (or some other signal causes the
> startup
> > process's latch to be set). Only then will it try to acquire the cleanup
> > lock again and broadcast another PROCSIG_RECOVERY_CONFLICT_BUFFERPIN
> message
> > if it fails to acquire the cleanup lock.
> > The unexpected behavior is in step (7), where it could be arbitrarily
> long
> > until the startup process is woken up again. The expected behavior is
> that
> > since max_standby_streaming_delay has already expired, the startup
> process
> > should wake up quickly and broadcast another
> > PROCSIG_RECOVERY_CONFLICT_BUFFERPIN message if there are still
> conflicting
> > backends.
> > I was able to reproduce this scenario with some custom code to control
> the
> > execution sequence.
> > One way to fix this scenario is to just remove the `if` block here [3]
> > entirely so that we always enable the STANDBY_TIMEOUT and
> > STANDBY_DEADLOCK_TIMEOUT timeouts.
> > [1]
> >
> https://github.com/postgres/postgres/blob/45c357e0e85d2dffe7af5440806150124a725a01/src/backend/storage/ipc/standby.c#L805
> > [2]
> >
> https://github.com/postgres/postgres/blob/45c357e0e85d2dffe7af5440806150124a725a01/src/backend/storage/ipc/standby.c#L842
> > [3]
> >
> https://github.com/postgres/postgres/blob/45c357e0e85d2dffe7af5440806150124a725a01/src/backend/storage/ipc/standby.c#L800-L806
>
> I agree this looks like a race condition, but I am not sure about the
> proposed solution. ResolveRecoveryConflictWithBufferPin() is called by
> LockBufferForCleanup() to wait for a process currently holding a
> buffer pin. However, new processes can still acquire the pin.. So I
> think the problem lies in the logic of the wakeup mechanism of the
> UnpinBuffer() no? The intended behavior is for the startup process to
> be woken regardless of Backend 2 subsequently acquiring the pin, but
> the current tracking mechanism is insufficient.
>
> --
> Regards,
> Dilip Kumar
> Google
>

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

    Dilip Kumar <dilipbalaut@gmail.com> — 2025-06-27T05:05:23Z

    On Thu, Jun 19, 2025 at 9:28 PM Anthony Hsu <erwaman@gmail.com> wrote:
>
> Yes, another option might be to change the wakeup logic so that the startup process is still woken up even if new processes have acquired the pin. The main thing is the startup process should be woken up promptly so that it can recheck if it can acquire the cleanup lock and if not, send PROCSIG_RECOVERY_CONFLICT_BUFFERPIN again to cancel any new backends.
>
> Before the standby limit time (default 30s) is reached, ResolveRecoveryConflictWithBufferPin will enable both a standby limit timeout and a deadlock timeout (default 1s). So if someone is holding a conflicting buffer pin for a long time, due to the deadlock timeout, the startup process will get woken up every 1s and recheck until we reach the standby limit, at which point it'll send the PROCSIG_RECOVERY_CONFLICT_BUFFERPIN. But after reaching standby limit, the next time the startup process does ResolveRecoveryConflictWithBufferPin, it only sends PROCSIG_RECOVERY_CONFLICT_BUFFERPIN without enabling the timeouts, which leads to the possibility of this race. So I thought a simple solution to address this race would be to just always enable the timeouts.

Again looking at the code and I got confused with the code placement
of ProcWaitForSignal(WAIT_EVENT_BUFFER_PIN);, I mean if we are already
behind then we broadcast 'PROCSIG_RECOVERY_CONFLICT_BUFFERPIN' and
then wait for WAIT_EVENT_BUFFER_PIN signal, Otherwise, we will wait on
timeouts, and once woken up by timeout we broadcast
'PROCSIG_RECOVERY_CONFLICT_BUFFERPIN' but now we don't bother to wait
for WAIT_EVENT_BUFFER_PIN.  If I am not missing something this
behavior seems inconsistent to me.

-- 
Regards,
Dilip Kumar
Google

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

    Anthony Hsu <erwaman@gmail.com> — 2025-06-27T06:11:34Z

    On Thu, Jun 26, 2025 at 10:05 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:

> On Thu, Jun 19, 2025 at 9:28 PM Anthony Hsu <erwaman@gmail.com> wrote:
> >
> > Yes, another option might be to change the wakeup logic so that the
> startup process is still woken up even if new processes have acquired the
> pin. The main thing is the startup process should be woken up promptly so
> that it can recheck if it can acquire the cleanup lock and if not, send
> PROCSIG_RECOVERY_CONFLICT_BUFFERPIN again to cancel any new backends.
> >
> > Before the standby limit time (default 30s) is reached,
> ResolveRecoveryConflictWithBufferPin will enable both a standby limit
> timeout and a deadlock timeout (default 1s). So if someone is holding a
> conflicting buffer pin for a long time, due to the deadlock timeout, the
> startup process will get woken up every 1s and recheck until we reach the
> standby limit, at which point it'll send the
> PROCSIG_RECOVERY_CONFLICT_BUFFERPIN. But after reaching standby limit, the
> next time the startup process does ResolveRecoveryConflictWithBufferPin, it
> only sends PROCSIG_RECOVERY_CONFLICT_BUFFERPIN without enabling the
> timeouts, which leads to the possibility of this race. So I thought a
> simple solution to address this race would be to just always enable the
> timeouts.
>
> Again looking at the code and I got confused with the code placement
> of ProcWaitForSignal(WAIT_EVENT_BUFFER_PIN);, I mean if we are already
> behind then we broadcast 'PROCSIG_RECOVERY_CONFLICT_BUFFERPIN' and
> then wait for WAIT_EVENT_BUFFER_PIN signal, Otherwise, we will wait on
> timeouts, and once woken up by timeout we broadcast
> 'PROCSIG_RECOVERY_CONFLICT_BUFFERPIN' but now we don't bother to wait
> for WAIT_EVENT_BUFFER_PIN.


If we get woken by the standby_delay timeout, we broadcast
PROCSIG_RECOVERY_CONFLICT_BUFFERPIN and then return from this method
(ResolveRecoveryConflictWithBufferPin) back to LockBufferForCleanup, which
will then loop back to the beginning of the for loop [1]. It will then
check if it is the exclusive pinner again, and if not,
re-enter ResolveRecoveryConflictWithBufferPin, and then wait for
WAIT_EVENT_BUFFER_PIN.

I've attached a patch fixing the race condition by always enabling the
standby limit and deadlock timeouts.

[1]
https://github.com/postgres/postgres/blob/94e2e150ec72a3b37e3847be99c4aca3320c38f9/src/backend/storage/buffer/bufmgr.c#L5710


> If I am not missing something this
> behavior seems inconsistent to me.
>
> --
> Regards,
> Dilip Kumar
> Google
>

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

    Dilip Kumar <dilipbalaut@gmail.com> — 2025-06-27T06:26:53Z

    On Fri, Jun 27, 2025 at 11:41 AM Anthony Hsu <erwaman@gmail.com> wrote:
>
>
>
> On Thu, Jun 26, 2025 at 10:05 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>>
>> On Thu, Jun 19, 2025 at 9:28 PM Anthony Hsu <erwaman@gmail.com> wrote:
>> >
>> > Yes, another option might be to change the wakeup logic so that the startup process is still woken up even if new processes have acquired the pin. The main thing is the startup process should be woken up promptly so that it can recheck if it can acquire the cleanup lock and if not, send PROCSIG_RECOVERY_CONFLICT_BUFFERPIN again to cancel any new backends.
>> >
>> > Before the standby limit time (default 30s) is reached, ResolveRecoveryConflictWithBufferPin will enable both a standby limit timeout and a deadlock timeout (default 1s). So if someone is holding a conflicting buffer pin for a long time, due to the deadlock timeout, the startup process will get woken up every 1s and recheck until we reach the standby limit, at which point it'll send the PROCSIG_RECOVERY_CONFLICT_BUFFERPIN. But after reaching standby limit, the next time the startup process does ResolveRecoveryConflictWithBufferPin, it only sends PROCSIG_RECOVERY_CONFLICT_BUFFERPIN without enabling the timeouts, which leads to the possibility of this race. So I thought a simple solution to address this race would be to just always enable the timeouts.
>>
>> Again looking at the code and I got confused with the code placement
>> of ProcWaitForSignal(WAIT_EVENT_BUFFER_PIN);, I mean if we are already
>> behind then we broadcast 'PROCSIG_RECOVERY_CONFLICT_BUFFERPIN' and
>> then wait for WAIT_EVENT_BUFFER_PIN signal, Otherwise, we will wait on
>> timeouts, and once woken up by timeout we broadcast
>> 'PROCSIG_RECOVERY_CONFLICT_BUFFERPIN' but now we don't bother to wait
>> for WAIT_EVENT_BUFFER_PIN.
>
>
> If we get woken by the standby_delay timeout, we broadcast PROCSIG_RECOVERY_CONFLICT_BUFFERPIN and then return from this method (ResolveRecoveryConflictWithBufferPin) back to LockBufferForCleanup, which will then loop back to the beginning of the for loop [1]. It will then check if it is the exclusive pinner again, and if not, re-enter ResolveRecoveryConflictWithBufferPin, and then wait for WAIT_EVENT_BUFFER_PIN.
>
Oh yeah, that's correct.

-- 
Regards,
Dilip Kumar
Google

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

    Anthony Hsu <erwaman@gmail.com> — 2025-06-28T23:37:13Z

    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.

[1]
https://github.com/postgres/postgres/blob/50fd428b2b9cb036c9c5982b56443d7e28119707/src/backend/storage/ipc/standby.c#L245-L258

On Thu, Jun 26, 2025 at 11:27 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:

> On Fri, Jun 27, 2025 at 11:41 AM Anthony Hsu <erwaman@gmail.com> wrote:
> >
> >
> >
> > On Thu, Jun 26, 2025 at 10:05 PM Dilip Kumar <dilipbalaut@gmail.com>
> wrote:
> >>
> >> On Thu, Jun 19, 2025 at 9:28 PM Anthony Hsu <erwaman@gmail.com> wrote:
> >> >
> >> > Yes, another option might be to change the wakeup logic so that the
> startup process is still woken up even if new processes have acquired the
> pin. The main thing is the startup process should be woken up promptly so
> that it can recheck if it can acquire the cleanup lock and if not, send
> PROCSIG_RECOVERY_CONFLICT_BUFFERPIN again to cancel any new backends.
> >> >
> >> > Before the standby limit time (default 30s) is reached,
> ResolveRecoveryConflictWithBufferPin will enable both a standby limit
> timeout and a deadlock timeout (default 1s). So if someone is holding a
> conflicting buffer pin for a long time, due to the deadlock timeout, the
> startup process will get woken up every 1s and recheck until we reach the
> standby limit, at which point it'll send the
> PROCSIG_RECOVERY_CONFLICT_BUFFERPIN. But after reaching standby limit, the
> next time the startup process does ResolveRecoveryConflictWithBufferPin, it
> only sends PROCSIG_RECOVERY_CONFLICT_BUFFERPIN without enabling the
> timeouts, which leads to the possibility of this race. So I thought a
> simple solution to address this race would be to just always enable the
> timeouts.
> >>
> >> Again looking at the code and I got confused with the code placement
> >> of ProcWaitForSignal(WAIT_EVENT_BUFFER_PIN);, I mean if we are already
> >> behind then we broadcast 'PROCSIG_RECOVERY_CONFLICT_BUFFERPIN' and
> >> then wait for WAIT_EVENT_BUFFER_PIN signal, Otherwise, we will wait on
> >> timeouts, and once woken up by timeout we broadcast
> >> 'PROCSIG_RECOVERY_CONFLICT_BUFFERPIN' but now we don't bother to wait
> >> for WAIT_EVENT_BUFFER_PIN.
> >
> >
> > If we get woken by the standby_delay timeout, we broadcast
> PROCSIG_RECOVERY_CONFLICT_BUFFERPIN and then return from this method
> (ResolveRecoveryConflictWithBufferPin) back to LockBufferForCleanup, which
> will then loop back to the beginning of the for loop [1]. It will then
> check if it is the exclusive pinner again, and if not, re-enter
> ResolveRecoveryConflictWithBufferPin, and then wait for
> WAIT_EVENT_BUFFER_PIN.
> >
> Oh yeah, that's correct.
>
> --
> Regards,
> Dilip Kumar
> Google
>

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

    Dilip Kumar <dilipbalaut@gmail.com> — 2025-06-30T03:28:33Z

    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

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

    Anthony Hsu <erwaman@gmail.com> — 2025-07-10T22:36:34Z

    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@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
>