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 <zhong950419@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CAGRkXqQio=7PWgTfKvjyQY9-7A_0A36E3put1gxJeDypgqFSzw@mail.gmail.com
Backpatch-through: 19

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);
 }
 

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;

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;