Hello Richard,
14.02.2026 11:41, Richard Guo wrote:
On Fri, Feb 13, 2026 at 7:09 PM PG Bug reporting form
<noreply@postgresql.org> wrote:
The following script:
CREATE TABLE t (i integer);
INSERT INTO t SELECT g FROM generate_series(1, 2) g;
SELECT SUM(i) OVER (ROWS BETWEEN 1 PRECEDING AND 0x7fffffffffffffff
FOLLOWING EXCLUDE CURRENT ROW) FROM t;
Thanks for the report. Reproduced here.
It seems to be caused by a signed integer overflow in row_is_in_frame
when calculating the frame's end position:
if (pos > winstate->currentpos + offset) return -1;
When offset is very large (close to INT64_MAX, as in the reported
case), the addition can overflow, in which case the result would wrap
to a negative number (with -fwrapv), causing the comparison to
incorrectly return true. In release builds, this causes valid rows to
be excluded from the window frame. In debug builds, it leads to an
assertion failure.
I think we can fix this by leveraging the overflow-aware integer
operation (ie, pg_add_s64_overflow) to perform the addition here. If
an overflow is detected, we can assume the frame boundary extends to
the end of the partition, meaning the current row is within the frame.
Thank you for looking at this!
The patch works for me, but I've just discovered one more similar anomaly:
SELECT SUM(i) OVER (ROWS BETWEEN 0x7fffffffffffffff FOLLOWING AND 1 FOLLOWING), i FROM t;
ERROR: XX000: window frame head moved backward
LOCATION: eval_windowaggregates, nodeWindowAgg.c:782
Best regards,
Alexander
