Re: Remove one TimestampTzGetDatum call in pg_stat_get_io()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Remove one TimestampTzGetDatum call in pg_stat_get_io()
Date: 2024-09-06 15:40:56
Message-ID: 2250103.1725637256@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Hmm, TimestampTzGetDatum is not a no-op on 32-bit machines. If you're
> correct about this, why are our 32-bit BF animals not crashing? Are
> we failing to test this code?

Oh, I had the polarity backwards: this error doesn't result in trying
to dereference something that's not a pointer, but rather in
constructing an extra indirection layer, with the end result being
that the timestamp displayed in the pg_stat_io view is garbage
(I saw output like "1999-12-31 19:11:45.880208-05" while testing in
a 32-bit VM). It's not so surprising that our regression tests are
insensitive to the values being displayed there.

I confirm that this fixes the problem. Will push shortly.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2024-09-06 15:45:27 Re: Remove one TimestampTzGetDatum call in pg_stat_get_io()
Previous Message Bertrand Drouvot 2024-09-06 15:03:17 Re: per backend I/O statistics