Re: Adding locks statistics

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Jeff Davis <pgsql(at)j-davis(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Adding locks statistics
Date: 2026-04-07 06:01:08
Message-ID: adSdpIjMWRR7YmbK@ip-10-97-1-34.eu-west-3.compute.internal
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2026-04-07 06:02:35 Re: Adding locks statistics
Previous Message Ashutosh Sharma 2026-04-07 05:50:41 Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication