Re: Adding locks statistics - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Adding locks statistics
Date
Msg-id acRqbLtT-aJDRSRl@paquier.xyz
Whole thread Raw
In response to Re: Adding locks statistics  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Adding locks statistics
List 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

pgsql-hackers by date:

Previous
From: Jim Jones
Date:
Subject: Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables
Next
From: Michael Paquier
Date:
Subject: Re: Remove unused at_sharedrel from autovac_table