Re: [PATCH] Change wait_time column of pg_stat_lock to double precision
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Tatsuya Kawata <kawatatatsuya0913@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2026-06-30T03:48:50Z
Lists: pgsql-hackers
On Mon, Jun 29, 2026 at 04:27:55AM +0000, Bertrand Drouvot wrote: > Hi, > > On Mon, Jun 29, 2026 at 11:11:06AM +0900, Michael Paquier wrote: >> Relying on long here is not reliable on WIN32, where the value could >> overflow for long wait times (where sizeof(long) == 4). I'd suggest a >> int64 or a uint64 instead for the API to be able to store wait times >> in usecs longer than the overflow threshold. That was another design >> oversight. My oversight here (aka I want to abolish completely the >> use of long in the core code; it leads to insanity). > > That makes sense and the lock time that would produce the overflow is realistic > (about 35 minutes) if my math is correct. Dealing with the "long" change, I have arrived at the conclusion that using int64 or even uint64 felt stupid because we already use a cast to PgStat_Counter in pgstat_count_lock_waits(), and some other stats just use PgStat_Counter when reporting usec times. So I have just switched the code to use PgStat_Counter. >> The counter is stored in usecs, displayed in msecs. Documenting it as >> stored in msecs is incorrect, no? > > Yeah, so this change. I need to re-learn how to read. And backpatched down to v19, catversion bump oblige. -- Michael
Commits
-
Change stat_lock.wait_time to double precision
- ff6f6e0470ec 19 (unreleased) landed
- c776550e4662 master landed