| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, 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-06 05:11:21 |
| Message-ID: | adNAec0VtP5J4q7m@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-04-06 05:15:04 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Previous Message | ls7777 | 2026-04-06 04:34:08 | Re: Patch for migration of the pg_commit_ts directory |