pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. 6+ messages / 1 participants [nested] [flat]
* pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. @ 2024-01-26 18:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-01-26 18:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 ------ master Details ------- https://git.postgresql.org/pg/commitdiff/25cd2d64021ae081cbcef1592e0ee04ddda2e975 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. @ 2024-01-26 18:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-01-26 18:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7204aea835d056ca97e86298c597a079d6ee8c97 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. @ 2024-01-26 18:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-01-26 18:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/86b6243a8ea92760679b6d9a8bbaab562b27a9db 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. @ 2024-01-26 18:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-01-26 18:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. @ 2024-01-26 18:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-01-26 18:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/425127bed2e72c0596fd35b976fde569f64f814d 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. @ 2024-01-26 18:40 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-01-26 18:40 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c3bdb25fb5f69e2b29b5d55725a134f95a9a423f 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-01-26 18:40 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-01-26 18:40 pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. Tom Lane <tgl@sss.pgh.pa.us> 2024-01-26 18:40 pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. Tom Lane <tgl@sss.pgh.pa.us> 2024-01-26 18:40 pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. Tom Lane <tgl@sss.pgh.pa.us> 2024-01-26 18:40 pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. Tom Lane <tgl@sss.pgh.pa.us> 2024-01-26 18:40 pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. Tom Lane <tgl@sss.pgh.pa.us> 2024-01-26 18:40 pgsql: Detect Julian-date overflow in timestamp[tz]_pl_interval. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox