Re: [PATCH] Change wait_time column of pg_stat_lock to double precision

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Change wait_time column of pg_stat_lock to double precision
Date: 2026-06-30 03:48:50
Message-ID: akM8otiB2LvovVak@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2026-06-30 03:51:44 Re: Row pattern recognition
Previous Message Fujii Masao 2026-06-30 03:36:39 Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10