Re: [PG19] btree_gin misses rows for a timestamptz bound in the repeated DST hour

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: shihao zhong <zhong950419(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PG19] btree_gin misses rows for a timestamptz bound in the repeated DST hour
Date: 2026-10-13 17:33:53
Message-ID: 732933.1791912833@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

shihao zhong <zhong950419(at)gmail(dot)com> writes:
> Since fc896821c44, a btree_gin index on a timestamp column can be
> used to compare with a timestamptz value. When that value is in the
> first pass of the repeated hour at the end of DST, the index scan
> misses rows.

Hm, good catch. The comparisons themselves are done correctly, but we
are failing to obtain a starting point that is guaranteed <= the first
matching index row.

> 0001 converts the start key back to timestamptz. If the result is
> after the bound, it moves the key earlier by the difference. Here the
> key becomes 00:30.

I think that's assuming way too much about the behavior of the
timezone code. I'd be inclined to use logic more along the line
of "compare to the original value using the relevant comparison
function; if greater, subtract an hour and try again".

Also, doesn't cvt_timestamptz_date have the same issue? I think
it'd only be at risk in a zone where midnight is part of the
repeatable hour, but there are some like that.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-10-13 18:00:37 pg_stat_statements: simplify SQL API version tracking
Previous Message Manu 2026-10-13 17:17:21 Re: Partition-aware simplification of constant IN lists after partition pruning