Re: Deadlock detector fails to activate on a hot standby replica - Mailing list pgsql-hackers

From Xuneng Zhou
Subject Re: Deadlock detector fails to activate on a hot standby replica
Date
Msg-id CABPTF7Wn-oW7jGZe1H1OBC-jwz2j3i9-4iG9=VGbkLtUY8NdBA@mail.gmail.com
Whole thread
In response to Re: Deadlock detector fails to activate on a hot standby replica  (JoongHyuk Shin <sjh910805@gmail.com>)
List pgsql-hackers
Hi,

On Tue, Sep 1, 2026 at 3:05 PM JoongHyuk Shin <sjh910805@gmail.com> wrote:
>
> I've read v8, though I haven't tested it.
> The recheck in RegisterPinCountWaiter() closes the window I described.
> I also think 0002 is worth keeping.

Sorry for the late reply here.

 * The caller must already be registered as the shared buffer's
+ * BM_PIN_COUNT_WAITER.

This line of comment for PinCountWaiterCheckReadyForCleanup in v8
seems not accurate to me. RegisterPinCountWaiter() explicitly permits
the shared bit BM_PIN_COUNT_WAITER to be absent. The invariante seems
to be:

Assert(PinCountWaitBuf == bufHdr); This process owns the logical
cleanup wait for this buffer.

Updated this, and extended the commit message like we discussed
earlier though it might not get used at the end. The timeout para in
that message is basically a summary of the first email in this thread.
I am not that familiar with it and too tired to proof-read it. Can you
do me a favor?

Beside these, I have no further comments on the patches. They seem to
be in good shape for a bug fix. Just wondering whether we need a test
for it.

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

Attachment

pgsql-hackers by date:

Previous
From: Dagfinn Ilmari Mannsåker
Date:
Subject: Re: pgcrypto: remove useless px_memset() and BF_ASM
Next
From: Nazir Bilal Yavuz
Date:
Subject: Re: [PATCH] Speed up pg_waldump TAP test and fix some GitHub CI Windows flakiness