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
processeshave acquired the pin. The main thing is the startup process should be woken up promptly so that it can
recheckif 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
standbylimit 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
timethe startup process does ResolveRecoveryConflictWithBufferPin, it only sends PROCSIG_RECOVERY_CONFLICT_BUFFERPIN
withoutenabling the timeouts, which leads to the possibility of this race. So I thought a simple solution to address
thisrace 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
