Hi,
On Fri, Sep 06, 2024 at 11:40:56AM -0400, Tom Lane wrote:
> 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
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 point
Bertrand Drouvot writes:
> While working on the per backend I/O statistics patch ([1]), I noticed that
> there is an unnecessary call to TimestampTzGetDatum() in pg_stat_get_io() (
> as the reset_time is already a Datum).
Hmm, TimestampTzGetDatum is not a no-op on 32-bit machines. If you're
corr
rom: Bertrand Drouvot
Date: Fri, 6 Sep 2024 08:47:37 +
Subject: [PATCH v1] Remove one TimestampTzGetDatum call in pg_stat_get_io()
When setting the tuple's value in pg_stat_get_io() there is no need to call
TimestampTzGetDatum() as reset_time is already a Datum.
---
src/backend/utils/adt/pgsta
