| commit | e69030cb5178347d499bbc549213e950064564fa | |
| author | Tom Lane <tgl@sss.pgh.pa.us> | |
| Fri, 6 Sep 2024 15:57:57 +0000 (6 11:57 -0400) | ||
| committer | Tom Lane <tgl@sss.pgh.pa.us> | |
| Fri, 6 Sep 2024 15:58:10 +0000 (6 11:58 -0400) | ||
| tree | 9cfd38c8728ba656ecfd4a50f04bc807a9246024 | treesnapshot (tar.gz zip) |
| parent | 446d5ad7ae7d3bf4fd08904ae54a6399cafb4e7d | commitdiff |
Fix incorrect pg_stat_io output on 32-bit machines.
pg_stat_get_io() applied TimestampTzGetDatum twice to the
stat_reset_timestamp value. On 64-bit builds that's harmless because
TimestampTzGetDatum is a no-op, but on 32-bit builds it results in
displaying garbage in the stats_reset column of the pg_stat_io view.
Bug dates to commit a9c70b46d which introduced pg_stat_io, so
back-patch to v16 where that came in.
Bertrand Drouvot
Discussion: https://postgr.es/m/Ztrd+XcPTz1zorkg@ip-10-97-1-34.eu-west-3.compute.internal
pg_stat_get_io() applied TimestampTzGetDatum twice to the
stat_reset_timestamp value. On 64-bit builds that's harmless because
TimestampTzGetDatum is a no-op, but on 32-bit builds it results in
displaying garbage in the stats_reset column of the pg_stat_io view.
Bug dates to commit a9c70b46d which introduced pg_stat_io, so
back-patch to v16 where that came in.
Bertrand Drouvot
Discussion: https://postgr.es/m/Ztrd+XcPTz1zorkg@ip-10-97-1-34.eu-west-3.compute.internal
| src/backend/utils/adt/pgstatfuncs.c | diffblobblamehistory |