public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tender Wang <[email protected]>
To: Richard Guo <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: BUG #19405: Assertion in eval_windowaggregates() fails due to integer overflow
Date: Sun, 15 Feb 2026 16:48:04 +0800
Message-ID: <CAHewXNnpM95Zg8ARhZwO87_6+4+ag5iBYhoaOJ0TAD_-ygm9tg@mail.gmail.com> (raw)
In-Reply-To: <CAMbWs4_GnG0NYnsBZJpHG-BLo28euD6VUx0WhFd4Ur6RaLr5WQ@mail.gmail.com>
References: <[email protected]>
<CAMbWs4_GnG0NYnsBZJpHG-BLo28euD6VUx0WhFd4Ur6RaLr5WQ@mail.gmail.com>
Richard Guo <[email protected]> 于2026年2月14日周六 17:41写道：
>
> On Fri, Feb 13, 2026 at 7:09 PM PG Bug reporting form
> <[email protected]> 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.
Yes, the code above may overflow; in debug builds, the assertion would fail.
>
> 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.
>
I've also considered similar solutions. But I'm not very familiar
with the window function
internal codes, so not sure it's the right fix.
> Right, I noticed this one too. Basically, nodeWindowAgg.c doesn't
> check for overflow when adding startOffsetValue or endOffsetValue.
> Since these values are provided by the user and can be arbitrarily
> large, simple addition does not seem safe. I think we may need to
> switch to overflow-aware integer operations in all relevant code.
>Here is an updated patch to fix all relevant code in nodeWindowAgg.c.
v2 seems to cover all cases. WFM.
In window.sql, we don't have a test case for this issue. I think we
should add it to the window.sql
--
Thanks,
Tender Wang
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: BUG #19405: Assertion in eval_windowaggregates() fails due to integer overflow
In-Reply-To: <CAHewXNnpM95Zg8ARhZwO87_6+4+ag5iBYhoaOJ0TAD_-ygm9tg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox