Обсуждение: BUG #19405: Assertion in eval_windowaggregates() fails due to integer overflow

The following bug has been logged on the website:

Bug reference:      19405
Logged by:          Alexander Lakhin
Email address:      exclusion@gmail.com
PostgreSQL version: 18.2
Operating system:   Ubuntu 24.04
Description:

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;

triggers:
TRAP: failed Assert("aggregatedupto_nonrestarted <=
winstate->aggregatedupto"), File: "nodeWindowAgg.c", Line: 1024, PID:
3288248
ExceptionalCondition at assert.c:51:13
eval_windowaggregates at nodeWindowAgg.c:1061:31
ExecWindowAgg at nodeWindowAgg.c:2367:5
ExecProcNode at executor.h:320:1
ExecutePlan at execMain.c:1711:10
standard_ExecutorRun at execMain.c:366:3
...

Reproduced on REL_14_STABLE .. master.

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.

- Richard

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

On Sat, Feb 14, 2026 at 7:00 PM Alexander Lakhin <exclusion@gmail.com> wrote:
> 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

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.

- Richard

On Sat, Feb 14, 2026 at 8:00 PM Richard Guo <guofenglinux@gmail.com> wrote:
> 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.

- Richard

Richard Guo <guofenglinux@gmail.com> 于2026年2月14日周六 17:41写道：
>
> 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.

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

On Sun, Feb 15, 2026 at 5:48 PM Tender Wang <tndrwang@gmail.com> wrote:
> 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

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.

- Richard