aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/timestamp.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-01-26 13:39:37 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2024-01-26 13:39:45 -0500
commit25cd2d64021ae081cbcef1592e0ee04ddda2e975 (patch)
treecc1ae50e139ce973074654e78f08fda055974fe4 /src/backend/utils/adt/timestamp.c
parent5ddf9973477729cf161b4ad0a1efd52f4fea9c88 (diff)
downloadpostgresql-25cd2d64021ae081cbcef1592e0ee04ddda2e975.tar.gz
postgresql-25cd2d64021ae081cbcef1592e0ee04ddda2e975.zip
Detect Julian-date overflow in timestamp[tz]_pl_interval.
We perform addition of the days field of an interval via arithmetic on the Julian-date representation of the timestamp's date. This step is subject to int32 overflow, and we also should not let the Julian date become very negative, for fear of weird results from j2date. (In the timestamptz case, allow a Julian date of -1 to pass, since it might convert back to zero after timezone rotation.) The additions of the months and microseconds fields could also overflow, of course. However, I believe we need no additional checks there; the existing range checks should catch such cases. The difficulty here is that j2date's magic modular arithmetic could produce something that looks like it's in-range. Per bug #18313 from Christian Maurer. This has been wrong for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/18313-64d2c8952d81e84b@postgresql.org
Diffstat (limited to 'src/backend/utils/adt/timestamp.c')
-rw-r--r--src/backend/utils/adt/timestamp.c27
1 files changed, 23 insertions, 4 deletions
diff --git a/src/backend/utils/adt/timestamp.c b/src/backend/utils/adt/timestamp.c
index 866fdd5af85..c38f88dba78 100644
--- a/src/backend/utils/adt/timestamp.c
+++ b/src/backend/utils/adt/timestamp.c
@@ -3120,8 +3120,16 @@ timestamp_pl_interval(PG_FUNCTION_ARGS)
(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
errmsg("timestamp out of range")));
- /* Add days by converting to and from Julian */
- julian = date2j(tm->tm_year, tm->tm_mon, tm->tm_mday) + span->day;
+ /*
+ * Add days by converting to and from Julian. We need an overflow
+ * check here since j2date expects a non-negative integer input.
+ */
+ julian = date2j(tm->tm_year, tm->tm_mon, tm->tm_mday);
+ if (pg_add_s32_overflow(julian, span->day, &julian) ||
+ julian < 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
+ errmsg("timestamp out of range")));
j2date(julian, &tm->tm_year, &tm->tm_mon, &tm->tm_mday);
if (tm2timestamp(tm, fsec, NULL, &timestamp) != 0)
@@ -3256,8 +3264,19 @@ timestamptz_pl_interval_internal(TimestampTz timestamp,
(errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
errmsg("timestamp out of range")));
- /* Add days by converting to and from Julian */
- julian = date2j(tm->tm_year, tm->tm_mon, tm->tm_mday) + span->day;
+ /*
+ * Add days by converting to and from Julian. We need an overflow
+ * check here since j2date expects a non-negative integer input.
+ * In practice though, it will give correct answers for small
+ * negative Julian dates; we should allow -1 to avoid
+ * timezone-dependent failures, as discussed in timestamp.h.
+ */
+ julian = date2j(tm->tm_year, tm->tm_mon, tm->tm_mday);
+ if (pg_add_s32_overflow(julian, span->day, &julian) ||
+ julian < -1)
+ ereport(ERROR,
+ (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
+ errmsg("timestamp out of range")));
j2date(julian, &tm->tm_year, &tm->tm_mon, &tm->tm_mday);
tz = DetermineTimeZoneOffset(tm, attimezone);