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

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Vitaly Davydov <v(dot)davydov(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Deadlock detector fails to activate on a hot standby replica
Date: 2026-06-23 03:13:49
Message-ID: CAHGQGwEykj-fTWSViwiSk=DKmb3tcE+zP_dm24+AoDZvar-HZw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 23, 2026 at 3:32 AM Vitaly Davydov <v(dot)davydov(at)postgrespro(dot)ru> wrote:
>
> Dear Fujii Masao, All
>
> While working on porting the patch to other majors, I've found that, the code
> in RegisterPinCountWaiter() (see below) should be improved because it doesn't
> unlock the bufHdr when the error is raised, as in LockBufferForCleanup().
> I guess it works, but it keeps the locks a bit longer.
>
> RegisterPinCountWaiter v5 patch code:
> ...
> if ((buf_state & BM_PIN_COUNT_WAITER) != 0 &&
> bufHdr->wait_backend_pgprocno != MyProcNumber)
> elog(ERROR, "multiple processes attempting to wait for pincount 1");
>
> RegisterPinCountWaiter proposed changes:
> ...
> if ((buf_state & BM_PIN_COUNT_WAITER) != 0 &&
> bufHdr->wait_backend_pgprocno != MyProcNumber)
> {
> UnlockBufHdr(bufHdr);
> elog(ERROR, "multiple processes attempting to wait for pincount 1");
> }
>
> What do you think?

You're right. Thanks for pointing out that!

I've updated the patch accordingly.

Regards,

--
Fujii Masao

Attachment Content-Type Size
v6-0001-Fix-deadlock-detector-activation-in-a-recovery-co.patch application/octet-stream 8.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Japin Li 2026-06-23 03:17:31 Re: md5_password_warnings for password auth with MD5-encrypted passwords
Previous Message Thomas Munro 2026-06-23 03:10:23 Re: Heads Up: cirrus-ci is shutting down June 1st