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

On Fri, Aug 14, 2026 at 1:35 AM Vitaly Davydov <vitprof(at)gmail(dot)com> wrote:
>
> Dear Xuneng Zhou, All
>
> Sorry for the delay. Starting from this moment I will use my personal email
> vitprof(at)gmail(dot)com instead of vdavydov(at)postgrespro(dot)ru.
>
> On 8/8/26 16:51, Xuneng Zhou wrote:
> > I haven't looked into the details yet. This version seems not resolve
> > the awkwardness of dependency you pointed out earlier. Just wondering
> > the reason for not aiming higher. It seems not trivial but still
> > feasible. Do you think we better try to land the bug fix first and do
> > further refactoring based on that?
>
> Yes, I haven't refactored the dependency. I think to fix the bug first
> to continue progress, but refactor it later. I think the future
> discussions about refactored versions may take a while.
>
> > "I agree with your comment. Furthermore, I do not like the approach of
> > locking and unlocking in different functions. But, I see this approach
> > is used in some other places in the code. I should think about how to improve it.
> >
> > I have some doubts about the code where LockBufferForCleanup (bufmgr.c)
> > calls ResolveRecoveryConflictWithBufferPin (standby.c), but the latter
> > function calls BufferIsReadyForCleanup (bufmgr.c). There is an idea to
> > refactor it in the future, because these functions are closely coupled.
> > May be unite them or move ResolveRecoveryConflictWithBufferPin into
> > bufmgr.c..."
>
> I agree, it should be refactored. The problem is that BufferIsReadyForCleanup
> uses some static variables from bufmgr.c. Moving
> ResolveRecoveryConflictWithBufferPin
> into bufmgr.c helps to break this dependency and looks good for me.
>
> I have some thoughts about the term 'pin count waiter'. I think it is a
> confusing name. There is an idea to name it as buffer writer, once
> multiple-readers-single-writer lock is implemented here. Pin count waiter
> is just another term for a buffer writer, I think.
>
> I propose to go further with the current change to speed up the progress
> because other contributors wait for it.

+1 for the maneuver. I'll review the latest offering.

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.