Re: Adding locks statistics - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Adding locks statistics
Date
Msg-id adNAec0VtP5J4q7m@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 Tue, Mar 31, 2026 at 07:10:51AM +0000, Bertrand Drouvot wrote:
> On Mon, Mar 30, 2026 at 06:11:17PM +0200, Tomas Vondra wrote:
>> Isn't pgstat_lock_flush_cb a bit broken with nowait=true? It'll skip
>> flushing stats for that particular lock type, but then it'll happily
>> reset the pending stats anyway, forgetting the stats.
>>
>> AFAIK it should keep the pending stats, and flush them sometime lager,
>> when the lock is not contended. That's what the other flush callbacks
>> do, at least. This probably means it needs to reset the entries one by
>> one, not the whole struct at once.
>
> Oh right, it's currently misbehaving, thanks for the warning!

Not misbehaving, mistaken.  This would create loss of stats data that
should have been flushed.  I should not have missed that, sorry about
that.  A single-lock approach is also something we do for SLRU and WAL
data, and these are much hotter.

At the exception of one comment that could be simplified, the code
removed is correct, so addressed this one as well.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Add missing stats_reset column to pg_stat_database_conflicts view
Next
From: Andres Freund
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?