Re: Adding locks statistics

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
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-03-25 23:06:20
Message-ID: acRqbLtT-aJDRSRl@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 25, 2026 at 07:54:42PM +0000, Bertrand Drouvot wrote:
> If you like the idea, maybe we could introduce query_until_stderr() in a separate
> commit. If you don't, then we could switch to looking in the server logfile
> instead of the session stderr.

I like the patch, but I happen to not like my initial idea of relying
on a NOTICE in an injection point combined with your new API in
BackgroundPsql because we can already achieve the same with a wait
injection point and use BackgroundPsql::query_until() with an \echo to
detect that the command is blocked.

The updated version attached uses this method (edited quickly your
commit message). Like your patch there is no need for hardcoded
sleeps and the CI's first impressions are actually good, but I am
going to need more runs to gain more confidence. Note I should be
able to do something here in 10 days or so. If you could confirm the
stability on your side for the time being with more runs, that would
help, of course.
--
Michael

Attachment Content-Type Size
v2-0001-Add-tests-for-lock-stats-take-two.patch text/plain 8.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-03-25 23:09:34 Re: Remove unused at_sharedrel from autovac_table
Previous Message Jim Jones 2026-03-25 23:00:02 Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables