pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval.
Date: 2024-01-26 18:40:03
Message-ID: E1rTR7T-003Et1-Db@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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

Branch
------
REL_14_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/3eb8a87f6e71b92ccb6618aac7f752a5e4e8d1dc

Modified Files
--------------
src/backend/utils/adt/timestamp.c | 27 +++++++++++++++++++++++----
src/test/regress/expected/horology.out | 4 ++++
src/test/regress/sql/horology.sql | 2 ++
3 files changed, 29 insertions(+), 4 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2024-01-26 20:54:25 pgsql: Compare varnullingrels too in assign_param_for_var().
Previous Message Robert Haas 2024-01-26 18:37:17 pgsql: Temporary patch to help debug pg_walsummary test failures.