Re: Deadlock detector fails to activate on a hot standby replica

Dear Fujii Masao,

On 6/10/26 11:42, Fujii Masao wrote:
> Could you review the v4 patches?

I've got the issue with BM_PIN_COUNT_WAITER. The origin of the issue is that
the other backend resets the flag before sending the notification (signal)
to the waiter. I agree with your changes where this flag is set again.

I would like to propose BufferIsReadyForCleanup function name instead of
BufferShouldWaitForCleanupLockForStandby (and change the returning value
semantics). There are other possible alternatives: BufferIsReadyForWriting,
BufferIsReadyForExclusiveAccess or something else. The code will look like
below:

if (BufferIsReadyForCleanup(bufid + 1))
break;

I've also found strange email in the commit messages like below:
Author: masao.fujii <masao(dot)fujii(at)masao(dot)fujii’s-MacBook-Pro>

I tried the modified 031 tap test but I do not see that it reproduces the issue
on the version without the fix. My version of 031 tap test hangs without the
fix. I haven't yet reviewed the tap test code at the moment, but I'm going to do
it as well.

Below one more note that is not directly related to the fix but may probably
improve the code readability.

1. BufferIsReadyForCleanup can be re-used with some small modifications in
LockBufferForCleanup like shown below:

LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
if (BufferIsReadyForCleanup())
{
// log recovery conflict
return;
}

In this case, we have to reset PM_PIN_COUNT_WAITER state in BufferIsReadyForCleanup:

if (buf_refcount == 1)
{
bufHdr->wait_backend_procno = -1;
PinCountWaitBuf = NULL;
UnlockBufHdrExt(bufHdr, 0, PM_PIN_COUNT_WAITER);
return false;
}

I may to prepare one more commit with this change.

With best regards,
Vitaly