Re: BUG #19405: Assertion in eval_windowaggregates() fails due to integer overflow
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Tender Wang <tndrwang@gmail.com>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2026-04-08T09:42:12Z
Lists: pgsql-bugs
Attachments
- v4-0001-Fix-integer-overflow-in-nodeWindowAgg.c.patch (application/octet-stream) patch v4-0001
On Tue, Feb 17, 2026 at 10:55 AM Richard Guo <guofenglinux@gmail.com> wrote: > I've included test cases covering the overflow scenarios for ROWS mode > in v3. (I failed to come up with queries for GROUPS mode that > demonstrate the bug, but I suspect I just haven't found the right test > case yet.) I have also included a commit message. Here is the updated patch. I've added test cases for GROUPS mode with an overflow-inducing offset. These don't seem to produce visibly wrong results without the patch. I believe that is because the incremental nature of group pointer advancement happens to mask the misbehavior. But I think they are still worth having since signed integer overflow is undefined behavior in C. Regarding performance, I don't think this should be a concern. pg_add_s64_overflow compiles down to a native add+jo sequence on platforms with __builtin_add_overflow, and falls back to a couple of inlined comparisons on others. Either way, the cost seems negligible next to the per-row tuple store and aggregation work these functions already do. - Richard
Commits
-
Fix integer overflow in nodeWindowAgg.c
- 305cf0df0c78 14.23 landed
- 4da71fc37a20 15.18 landed
- 0fe032e6a666 16.14 landed
- f8736f8bc531 17.10 landed
- bfc7dff26d53 18.4 landed
- 8b6c89e377b5 19 (unreleased) landed