diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2024-02-28 14:00:30 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2024-02-28 14:00:30 -0500 |
commit | fe3b1b575e24748ddb9b3b67394fa10c279090ac (patch) | |
tree | 2f237bfcf6553b6d5552033b75aeed1ab16a08de /src/backend/utils/adt/timestamp.c | |
parent | 09f09884c18d725db7a60e03a8f78bafdbc78b95 (diff) | |
download | postgresql-fe3b1b575e24748ddb9b3b67394fa10c279090ac.tar.gz postgresql-fe3b1b575e24748ddb9b3b67394fa10c279090ac.zip |
Fix mis-rounding and overflow hazards in date_bin().
In the case where the target timestamp is before the origin timestamp
and their difference is already an exact multiple of the stride, the
code incorrectly subtracted the stride anyway.
Also detect several integer-overflow cases that previously produced
bogus results. (The submitted patch tried to avoid overflow, but
I'm not convinced it's right, and problematic cases are so far out of
the plausibly-useful range that they don't seem worth sweating over.
Let's just use overflow-detecting arithmetic and throw errors.)
timestamp_bin() and timestamptz_bin() are basically identical and
so had identical bugs. Fix both.
Report and patch by Moaaz Assali, adjusted some by me. Back-patch
to v14 where date_bin() was introduced.
Discussion: https://postgr.es/m/CALkF+nvtuas-2kydG-WfofbRSJpyODAJWun==W-yO5j2R4meqA@mail.gmail.com
Diffstat (limited to 'src/backend/utils/adt/timestamp.c')
-rw-r--r-- | src/backend/utils/adt/timestamp.c | 72 |
1 files changed, 53 insertions, 19 deletions
diff --git a/src/backend/utils/adt/timestamp.c b/src/backend/utils/adt/timestamp.c index 6dbc27a48d1..78d748cddaf 100644 --- a/src/backend/utils/adt/timestamp.c +++ b/src/backend/utils/adt/timestamp.c @@ -3870,8 +3870,9 @@ timestamp_bin(PG_FUNCTION_ARGS) Timestamp timestamp = PG_GETARG_TIMESTAMP(1); Timestamp origin = PG_GETARG_TIMESTAMP(2); Timestamp result, - tm_diff, stride_usecs, + tm_diff, + tm_modulo, tm_delta; if (TIMESTAMP_NOT_FINITE(timestamp)) @@ -3887,24 +3888,40 @@ timestamp_bin(PG_FUNCTION_ARGS) (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), errmsg("timestamps cannot be binned into intervals containing months or years"))); - stride_usecs = stride->day * USECS_PER_DAY + stride->time; + if (unlikely(pg_mul_s64_overflow(stride->day, USECS_PER_DAY, &stride_usecs)) || + unlikely(pg_add_s64_overflow(stride_usecs, stride->time, &stride_usecs))) + ereport(ERROR, + (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE), + errmsg("interval out of range"))); if (stride_usecs <= 0) ereport(ERROR, (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE), errmsg("stride must be greater than zero"))); - tm_diff = timestamp - origin; - tm_delta = tm_diff - tm_diff % stride_usecs; + if (unlikely(pg_sub_s64_overflow(timestamp, origin, &tm_diff))) + ereport(ERROR, + (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE), + errmsg("interval out of range"))); + + /* These calculations cannot overflow */ + tm_modulo = tm_diff % stride_usecs; + tm_delta = tm_diff - tm_modulo; + result = origin + tm_delta; /* - * Make sure the returned timestamp is at the start of the bin, even if - * the origin is in the future. + * We want to round towards -infinity, not 0, when tm_diff is negative and + * not a multiple of stride_usecs. This adjustment *can* cause overflow, + * since the result might now be out of the range origin .. timestamp. */ - if (origin > timestamp && stride_usecs > 1) - tm_delta -= stride_usecs; - - result = origin + tm_delta; + if (tm_modulo < 0) + { + if (unlikely(pg_sub_s64_overflow(result, stride_usecs, &result)) || + !IS_VALID_TIMESTAMP(result)) + ereport(ERROR, + (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE), + errmsg("timestamp out of range"))); + } PG_RETURN_TIMESTAMP(result); } @@ -4055,6 +4072,7 @@ timestamptz_bin(PG_FUNCTION_ARGS) TimestampTz result, stride_usecs, tm_diff, + tm_modulo, tm_delta; if (TIMESTAMP_NOT_FINITE(timestamp)) @@ -4070,24 +4088,40 @@ timestamptz_bin(PG_FUNCTION_ARGS) (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), errmsg("timestamps cannot be binned into intervals containing months or years"))); - stride_usecs = stride->day * USECS_PER_DAY + stride->time; + if (unlikely(pg_mul_s64_overflow(stride->day, USECS_PER_DAY, &stride_usecs)) || + unlikely(pg_add_s64_overflow(stride_usecs, stride->time, &stride_usecs))) + ereport(ERROR, + (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE), + errmsg("interval out of range"))); if (stride_usecs <= 0) ereport(ERROR, (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE), errmsg("stride must be greater than zero"))); - tm_diff = timestamp - origin; - tm_delta = tm_diff - tm_diff % stride_usecs; + if (unlikely(pg_sub_s64_overflow(timestamp, origin, &tm_diff))) + ereport(ERROR, + (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE), + errmsg("interval out of range"))); + + /* These calculations cannot overflow */ + tm_modulo = tm_diff % stride_usecs; + tm_delta = tm_diff - tm_modulo; + result = origin + tm_delta; /* - * Make sure the returned timestamp is at the start of the bin, even if - * the origin is in the future. + * We want to round towards -infinity, not 0, when tm_diff is negative and + * not a multiple of stride_usecs. This adjustment *can* cause overflow, + * since the result might now be out of the range origin .. timestamp. */ - if (origin > timestamp && stride_usecs > 1) - tm_delta -= stride_usecs; - - result = origin + tm_delta; + if (tm_modulo < 0) + { + if (unlikely(pg_sub_s64_overflow(result, stride_usecs, &result)) || + !IS_VALID_TIMESTAMP(result)) + ereport(ERROR, + (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE), + errmsg("timestamp out of range"))); + } PG_RETURN_TIMESTAMPTZ(result); } |