From aadce2c10ffec9326a5119a3c590b77ab58b4f97 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 14 Oct 2026 18:45:28 -0400 Subject: [PATCH] btree_gin: Fix timestamp-vs-timestamptz comparisons near DST boundary. To perform cross-type index scans with a timestamp index and a timestamptz comparison value, btree_gin must convert the timestamptz to timestamp to establish the starting point for the indexscan. This is hazardous because timestamp_cmp_timestamptz is actually defined to upconvert the timestamp to timestamptz and then compare timestamptz's. When dealing with ambiguous timestamps near a fall-back DST transition, the value may not round-trip, leading to selecting a scan start point that misses some index entries that should match. To fix that, move the converted value back an hour at a time until it's clearly <= the given comparison value. (We could try to be smarter, but this way seems more certain to work across all possible DST behaviors.) Another hazard is that for timestamptz's that are finite but close to the upper range limit, the conversion may produce timestamp +Infinity, again comparing greater than the given value. It's less clear whether this can lead to missing matching values in practice, but it would at least risk making the aforesaid correction loop very slow. So replace +Infinity by the maximum finite timestamp. The reverse case of timestamptz index and timestamp comparison value is not at risk because upconverting the timestamp stays consistent with what timestamptz_cmp_timestamp will do. Also, while date-vs-timestamptz could theoretically be at risk, the conversion error would have to be a full day which seems not to occur in reality. Author: shihao zhong Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAGRkXqQio=7PWgTfKvjyQY9-7A_0A36E3put1gxJeDypgqFSzw@mail.gmail.com Backpatch-through: 19 --- contrib/btree_gin/btree_gin.c | 28 ++++++++++++++++++++++++ contrib/btree_gin/expected/timestamp.out | 26 ++++++++++++++++++++++ contrib/btree_gin/sql/timestamp.sql | 9 ++++++++ 3 files changed, 63 insertions(+) diff --git a/contrib/btree_gin/btree_gin.c b/contrib/btree_gin/btree_gin.c index 8dfbaa4781d..4fb38ac22e4 100644 --- a/contrib/btree_gin/btree_gin.c +++ b/contrib/btree_gin/btree_gin.c @@ -513,6 +513,34 @@ cvt_timestamptz_timestamp(Datum input) result = timestamptz2timestamp_safe(val, (Node *) &escontext); /* We can ignore errors, since result is useful as-is */ + + /* + * It is critical that result <= val, else the index scan can begin after + * potentially-matching index entries. There are two known ways that this + * might fail to be true: + * + * 1. In the to-be-repeated hour of a fall-back DST transition, the + * ambiguous converted timestamp will be interpreted by <= as the later + * (standard-time) timestamptz, thus comparing later than the given val. + * + * 2. timestamptz2timestamp_safe will return +Infinity if the input is + * close to the range limit of timestamptz and its rotated value would + * exceed the limit of timestamp. (In itself this might not cause any + * failures, but if #1 also applies then it possibly could. In any case + * we don't want to be repeatedly subtracting an hour from +Infinity.) + * + * To fix both things, first replace +Infinity with the maximum finite + * timestamp, and then back up an hour at a time until we have a result + * that compares <= val. (It won't hurt if we end with a result that is + * slightly less than the nominal lower limit of timestamp.) This may + * result in scanning more index entries than we really need to, but we + * won't miss any we need. + */ + if (TIMESTAMP_IS_NOEND(result)) + result = END_TIMESTAMP; + while (timestamp_cmp_timestamptz_internal(result, val) > 0) + result -= USECS_PER_HOUR; + return TimestampGetDatum(result); } diff --git a/contrib/btree_gin/expected/timestamp.out b/contrib/btree_gin/expected/timestamp.out index b7565285e68..6e972b56602 100644 --- a/contrib/btree_gin/expected/timestamp.out +++ b/contrib/btree_gin/expected/timestamp.out @@ -343,3 +343,29 @@ SELECT * FROM test_timestamp WHERE i>'4714-11-23 17:00 BC'::timestamptz ORDER BY infinity (7 rows) +-- Check that we aren't fooled by ambiguous timestamps near a DST transition +INSERT INTO test_timestamp VALUES + ('2026-11-01 00:50'), ('2026-11-01 01:10'), ('2026-11-01 01:20'), + ('2026-11-01 01:40'), ('2026-11-01 02:10'); +SET TimeZone = 'America/New_York'; +SELECT * FROM test_timestamp WHERE i>='2026-11-01 01:30-04'::timestamptz ORDER BY i; + i +-------------------------- + Sun Nov 01 01:10:00 2026 + Sun Nov 01 01:20:00 2026 + Sun Nov 01 01:40:00 2026 + Sun Nov 01 02:10:00 2026 + infinity +(5 rows) + +SELECT * FROM test_timestamp WHERE i>'2026-11-01 01:30-04'::timestamptz ORDER BY i; + i +-------------------------- + Sun Nov 01 01:10:00 2026 + Sun Nov 01 01:20:00 2026 + Sun Nov 01 01:40:00 2026 + Sun Nov 01 02:10:00 2026 + infinity +(5 rows) + +RESET TimeZone; diff --git a/contrib/btree_gin/sql/timestamp.sql b/contrib/btree_gin/sql/timestamp.sql index 1ee4edb5ea4..750ab6d2336 100644 --- a/contrib/btree_gin/sql/timestamp.sql +++ b/contrib/btree_gin/sql/timestamp.sql @@ -71,3 +71,12 @@ SELECT * FROM test_timestamp WHERE i>'infinity'::timestamptz ORDER BY i; -- This PST timestamptz will underflow if converted to timestamp SELECT * FROM test_timestamp WHERE i<='4714-11-23 17:00 BC'::timestamptz ORDER BY i; SELECT * FROM test_timestamp WHERE i>'4714-11-23 17:00 BC'::timestamptz ORDER BY i; + +-- Check that we aren't fooled by ambiguous timestamps near a DST transition +INSERT INTO test_timestamp VALUES + ('2026-11-01 00:50'), ('2026-11-01 01:10'), ('2026-11-01 01:20'), + ('2026-11-01 01:40'), ('2026-11-01 02:10'); +SET TimeZone = 'America/New_York'; +SELECT * FROM test_timestamp WHERE i>='2026-11-01 01:30-04'::timestamptz ORDER BY i; +SELECT * FROM test_timestamp WHERE i>'2026-11-01 01:30-04'::timestamptz ORDER BY i; +RESET TimeZone;