Re: Adding locks statistics - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Adding locks statistics
Date
Msg-id adSdpIjMWRR7YmbK@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Adding locks statistics  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Adding locks statistics
List pgsql-hackers
Hi,

On Tue, Apr 07, 2026 at 01:21:39PM +0900, Michael Paquier wrote:
> On Mon, Apr 06, 2026 at 03:34:44PM +0900, Michael Paquier wrote:
> > This one was a simple puzzle: there was a race condition between the
> > detach done by a local point and the wait/detach sequence.  As we want
> > a detach, dropping the local point is proving to work here.
> > 
> > I am going to do a few more runs to gain some more confidence.
> 
> Done a total of 5 runs (or 6 actually), and fixed it.
> 
> > Bertrand, could you confirm please?
> 
> That's of course always welcome.  I'll keep an eye on the CI and the
> buildfarm.

That looks to work, thanks! But I was wondering if this new version is not
introducing a new race: the injection point is not local anymore so it could be
that another process reach the new injection point. That said, even if this is
the case I think we're ok since s2 is using "query_until" so we could say that
"at least" s2 reached the injection point. The new version does not ensure that
"only" s2 reached the injection point but I think that's safe.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Next
From: Bertrand Drouvot
Date:
Subject: Re: Adding locks statistics