Fix and simplify some usages of TimestampDifference().
authorTom Lane <[email protected]>
Wed, 11 Nov 2020 03:51:19 +0000 (22:51 -0500)
committerTom Lane <[email protected]>
Wed, 11 Nov 2020 03:51:58 +0000 (22:51 -0500)
commit210564a74409f79cb1441fab62c4154dd148840f
tree14df7f4fee946fc01491469f15d07fc2038cdfc1
parentf93f1a21ae62fe4650335d5818b806f86928d2c2
Fix and simplify some usages of TimestampDifference().

Introduce TimestampDifferenceMilliseconds() to simplify callers
that would rather have the difference in milliseconds, instead of
the select()-oriented seconds-and-microseconds format.  This gets
rid of at least one integer division per call, and it eliminates
some apparently-easy-to-mess-up arithmetic.

Two of these call sites were in fact wrong:

* pg_prewarm's autoprewarm_main() forgot to multiply the seconds
by 1000, thus ending up with a delay 1000X shorter than intended.
That doesn't quite make it a busy-wait, but close.

* postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute
microseconds not milliseconds, thus ending up with a delay 1000X longer
than intended.  Somebody along the way had noticed this problem but
misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather
than fixing the units.  This was relatively harmless in context, because
we don't care that much about exactly how long this delay is; still,
it's wrong.

There are a few more callers of TimestampDifference() that don't
have a direct need for seconds-and-microseconds, but can't use
TimestampDifferenceMilliseconds() either because they do need
microsecond precision or because they might possibly deal with
intervals long enough to overflow 32-bit milliseconds.  It might be
worth inventing another API to improve that, but that seems outside
the scope of this patch; so those callers are untouched here.

Given the fact that we are fixing some bugs, and the likelihood
that future patches might want to back-patch code that uses this
new API, back-patch to all supported branches.

Alexey Kondratov and Tom Lane

Discussion: https://postgr.es/m/3b1c053a21c07c1ed5e00be3b2b855ef@postgrespro.ru
contrib/postgres_fdw/connection.c
src/backend/access/transam/xlog.c
src/backend/replication/walreceiverfuncs.c
src/backend/replication/walsender.c
src/backend/utils/adt/timestamp.c
src/include/utils/timestamp.h