Improve TimestampDifferenceMilliseconds to cope with overflow sanely.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 26 Jan 2023 22:09:12 +0000 (17:09 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 26 Jan 2023 22:09:12 +0000 (17:09 -0500)
commit3a28d78089289794fda86cdbd275fc4756c6c6aa
treee7a3e527c46c57d272a7a67ef3d353f33a16e5de
parent24ff700f6aee2e8b915399e03934c6fe9b593d3f
Improve TimestampDifferenceMilliseconds to cope with overflow sanely.

We'd like to use TimestampDifferenceMilliseconds with the stop_time
possibly being TIMESTAMP_INFINITY, but up to now it's disclaimed
responsibility for overflow cases.  Define it to clamp its output to
the range [0, INT_MAX], handling overflow correctly.  (INT_MAX rather
than LONG_MAX seems appropriate, because the function is already
described as being intended for calculating wait times for WaitLatch
et al, and that infrastructure only handles waits up to INT_MAX.
Also, this choice gets rid of cross-platform behavioral differences.)

Having done that, we can replace some ad-hoc code in walreceiver.c
with a simple call to TimestampDifferenceMilliseconds.

While at it, fix some buglets in existing callers of
TimestampDifferenceMilliseconds: basebackup_copy.c had not read the
memo about TimestampDifferenceMilliseconds never returning a negative
value, and postmaster.c had not read the memo about Min() and Max()
being macros with multiple-evaluation hazards.  Neither of these
quite seem worth back-patching.

Patch by me; thanks to Nathan Bossart for review.

Discussion: https://postgr.es/m/3126727.1674759248@sss.pgh.pa.us
src/backend/backup/basebackup_copy.c
src/backend/postmaster/postmaster.c
src/backend/replication/walreceiver.c
src/backend/utils/adt/timestamp.c