| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19405: Assertion in eval_windowaggregates() fails due to integer overflow |
| Date: | 2026-02-14 09:41:00 |
| Message-ID: | CAMbWs4_GnG0NYnsBZJpHG-BLo28euD6VUx0WhFd4Ur6RaLr5WQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Feb 13, 2026 at 7:09 PM PG Bug reporting form
<noreply(at)postgresql(dot)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.
- Richard
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-signed-integer-overflow-in-nodeWindowAgg.c.patch | application/octet-stream | 1.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2026-02-14 10:00:00 | Re: BUG #19405: Assertion in eval_windowaggregates() fails due to integer overflow |
| Previous Message | Michael Banck | 2026-02-14 09:05:02 | Re: 17.8 standby crashes during WAL replay from 17.5 primary: "could not access status of transaction" |