public inbox for [email protected]
help / color / mirror / Atom feedFrom: Richard Guo <[email protected]>
To: Tender Wang <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: BUG #19405: Assertion in eval_windowaggregates() fails due to integer overflow
Date: Tue, 17 Feb 2026 10:55:30 +0900
Message-ID: <CAMbWs4-stRKsWK6JXYn1eaR1JJzxAeF7QULQ-=0mJFX9k4RFzA@mail.gmail.com> (raw)
In-Reply-To: <CAHewXNnpM95Zg8ARhZwO87_6+4+ag5iBYhoaOJ0TAD_-ygm9tg@mail.gmail.com>
References: <[email protected]>
<CAMbWs4_GnG0NYnsBZJpHG-BLo28euD6VUx0WhFd4Ur6RaLr5WQ@mail.gmail.com>
<CAHewXNnpM95Zg8ARhZwO87_6+4+ag5iBYhoaOJ0TAD_-ygm9tg@mail.gmail.com>
On Sun, Feb 15, 2026 at 5:48 PM Tender Wang <[email protected]> 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
Attachments:
[application/octet-stream] v3-0001-Fix-integer-overflow-in-nodeWindowAgg.c.patch (8.3K, 2-v3-0001-Fix-integer-overflow-in-nodeWindowAgg.c.patch)
download | inline diff:
From dc904955a11580150b84cb9eb5c536926b10fb2a Mon Sep 17 00:00:00 2001
From: Richard Guo <[email protected]>
Date: Sat, 14 Feb 2026 18:16:27 +0900
Subject: [PATCH v3] Fix integer overflow in nodeWindowAgg.c
In nodeWindowAgg.c, the calculations for frame start and end positions
in ROWS and GROUPS modes were performed using simple integer addition.
If a user-supplied offset was sufficiently large (close to INT64_MAX),
adding it to the current row or group index could cause a signed
integer overflow, wrapping the result to a negative number.
This led to incorrect behavior where frame boundaries that should have
extended indefinitely (or beyond the partition end) were treated as
falling at the first row, or where valid rows were incorrectly marked
as out-of-frame. Depending on the specific query and data, these
overflows can result in incorrect query results, execution errors, or
assertion failures.
To fix, use overflow-aware integer addition (ie, pg_add_s64_overflow)
to check for overflows during these additions. If an overflow is
detected, the boundary is now clamped to INT64_MAX. This ensures the
logic correctly treats the boundary as extending to the end of the
partition.
---
src/backend/executor/nodeWindowAgg.c | 57 +++++++++++++++++++++++++---
src/test/regress/expected/window.out | 52 +++++++++++++++++++++++++
src/test/regress/sql/window.sql | 13 +++++++
3 files changed, 117 insertions(+), 5 deletions(-)
diff --git a/src/backend/executor/nodeWindowAgg.c b/src/backend/executor/nodeWindowAgg.c
index d9b64b0f465..628086930bf 100644
--- a/src/backend/executor/nodeWindowAgg.c
+++ b/src/backend/executor/nodeWindowAgg.c
@@ -37,6 +37,7 @@
#include "catalog/objectaccess.h"
#include "catalog/pg_aggregate.h"
#include "catalog/pg_proc.h"
+#include "common/int.h"
#include "executor/executor.h"
#include "executor/nodeWindowAgg.h"
#include "miscadmin.h"
@@ -1532,12 +1533,22 @@ row_is_in_frame(WindowObject winobj, int64 pos, TupleTableSlot *slot,
if (frameOptions & FRAMEOPTION_ROWS)
{
int64 offset = DatumGetInt64(winstate->endOffsetValue);
+ int64 frameendpos;
/* rows after current row + offset are out of frame */
if (frameOptions & FRAMEOPTION_END_OFFSET_PRECEDING)
offset = -offset;
- if (pos > winstate->currentpos + offset)
+ if (pg_add_s64_overflow(winstate->currentpos, offset, &frameendpos))
+ {
+ /*
+ * If we have an overflow, it means the frame end is beyond
+ * the range of int64. Since currentpos >= 0, this can only
+ * be a positive overflow. We treat this as meaning that the
+ * frame extends to end of partition.
+ */
+ }
+ else if (pos > frameendpos)
return -1;
}
else if (frameOptions & (FRAMEOPTION_RANGE | FRAMEOPTION_GROUPS))
@@ -1672,7 +1683,16 @@ update_frameheadpos(WindowAggState *winstate)
if (frameOptions & FRAMEOPTION_START_OFFSET_PRECEDING)
offset = -offset;
- winstate->frameheadpos = winstate->currentpos + offset;
+ /*
+ * If we have an overflow, it means the frame head is beyond the
+ * range of int64. Since currentpos >= 0, this can only be a
+ * positive overflow. We treat this as being beyond end of
+ * partition.
+ */
+ if (pg_add_s64_overflow(winstate->currentpos, offset,
+ &winstate->frameheadpos))
+ winstate->frameheadpos = PG_INT64_MAX;
+
/* frame head can't go before first row */
if (winstate->frameheadpos < 0)
winstate->frameheadpos = 0;
@@ -1789,7 +1809,16 @@ update_frameheadpos(WindowAggState *winstate)
if (frameOptions & FRAMEOPTION_START_OFFSET_PRECEDING)
minheadgroup = winstate->currentgroup - offset;
else
- minheadgroup = winstate->currentgroup + offset;
+ {
+ /*
+ * If we have an overflow, it means the target group is beyond
+ * the range of int64. We treat this as "infinity", which
+ * ensures the loop below advances to end of partition.
+ */
+ if (pg_add_s64_overflow(winstate->currentgroup, offset,
+ &minheadgroup))
+ minheadgroup = PG_INT64_MAX;
+ }
tuplestore_select_read_pointer(winstate->buffer,
winstate->framehead_ptr);
@@ -1926,7 +1955,16 @@ update_frametailpos(WindowAggState *winstate)
if (frameOptions & FRAMEOPTION_END_OFFSET_PRECEDING)
offset = -offset;
- winstate->frametailpos = winstate->currentpos + offset + 1;
+ /*
+ * If we have an overflow, it means the frame tail is beyond the
+ * range of int64. Since currentpos >= 0, this can only be a
+ * positive overflow. We treat this as being beyond end of
+ * partition.
+ */
+ if (pg_add_s64_overflow(winstate->currentpos + 1, offset,
+ &winstate->frametailpos))
+ winstate->frametailpos = PG_INT64_MAX;
+
/* smallest allowable value of frametailpos is 0 */
if (winstate->frametailpos < 0)
winstate->frametailpos = 0;
@@ -2043,7 +2081,16 @@ update_frametailpos(WindowAggState *winstate)
if (frameOptions & FRAMEOPTION_END_OFFSET_PRECEDING)
maxtailgroup = winstate->currentgroup - offset;
else
- maxtailgroup = winstate->currentgroup + offset;
+ {
+ /*
+ * If we have an overflow, it means the target group is beyond
+ * the range of int64. We treat this as "infinity", which
+ * ensures the loop below advances to end of partition.
+ */
+ if (pg_add_s64_overflow(winstate->currentgroup, offset,
+ &maxtailgroup))
+ maxtailgroup = PG_INT64_MAX;
+ }
tuplestore_select_read_pointer(winstate->buffer,
winstate->frametail_ptr);
diff --git a/src/test/regress/expected/window.out b/src/test/regress/expected/window.out
index 7a04d3a7a9f..08cbb4cab4d 100644
--- a/src/test/regress/expected/window.out
+++ b/src/test/regress/expected/window.out
@@ -1361,6 +1361,58 @@ SELECT pg_get_viewdef('v_window');
FROM generate_series(now(), (now() + '@ 100 days'::interval), '@ 1 hour'::interval) i(i);
(1 row)
+-- test overflow frame specifications
+SELECT sum(unique1) over (rows between current row and 0x7fffffffffffffff following exclude current row),
+ unique1, four
+FROM tenk1 WHERE unique1 < 10;
+ sum | unique1 | four
+-----+---------+------
+ 41 | 4 | 0
+ 39 | 2 | 2
+ 38 | 1 | 1
+ 32 | 6 | 2
+ 23 | 9 | 1
+ 15 | 8 | 0
+ 10 | 5 | 1
+ 7 | 3 | 3
+ 0 | 7 | 3
+ | 0 | 0
+(10 rows)
+
+SELECT sum(unique1) over (rows between 0x7fffffffffffffff following and 1 following),
+ unique1, four
+FROM tenk1 WHERE unique1 < 10;
+ sum | unique1 | four
+-----+---------+------
+ | 4 | 0
+ | 2 | 2
+ | 1 | 1
+ | 6 | 2
+ | 9 | 1
+ | 8 | 0
+ | 5 | 1
+ | 3 | 3
+ | 7 | 3
+ | 0 | 0
+(10 rows)
+
+SELECT last_value(unique1) over (ORDER BY four rows between current row and 0x7fffffffffffffff following exclude current row),
+ unique1, four
+FROM tenk1 WHERE unique1 < 10;
+ last_value | unique1 | four
+------------+---------+------
+ 7 | 0 | 0
+ 7 | 8 | 0
+ 7 | 4 | 0
+ 7 | 5 | 1
+ 7 | 9 | 1
+ 7 | 1 | 1
+ 7 | 6 | 2
+ 7 | 2 | 2
+ 7 | 3 | 3
+ | 7 | 3
+(10 rows)
+
-- RANGE offset PRECEDING/FOLLOWING tests
SELECT sum(unique1) over (order by four range between 2::int8 preceding and 1::int2 preceding),
unique1, four
diff --git a/src/test/regress/sql/window.sql b/src/test/regress/sql/window.sql
index 37d837a2f66..589f277f267 100644
--- a/src/test/regress/sql/window.sql
+++ b/src/test/regress/sql/window.sql
@@ -330,6 +330,19 @@ CREATE TEMP VIEW v_window AS
SELECT pg_get_viewdef('v_window');
+-- test overflow frame specifications
+SELECT sum(unique1) over (rows between current row and 0x7fffffffffffffff following exclude current row),
+ unique1, four
+FROM tenk1 WHERE unique1 < 10;
+
+SELECT sum(unique1) over (rows between 0x7fffffffffffffff following and 1 following),
+ unique1, four
+FROM tenk1 WHERE unique1 < 10;
+
+SELECT last_value(unique1) over (ORDER BY four rows between current row and 0x7fffffffffffffff following exclude current row),
+ unique1, four
+FROM tenk1 WHERE unique1 < 10;
+
-- RANGE offset PRECEDING/FOLLOWING tests
SELECT sum(unique1) over (order by four range between 2::int8 preceding and 1::int2 preceding),
--
2.39.5 (Apple Git-154)
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: <CAMbWs4-stRKsWK6JXYn1eaR1JJzxAeF7QULQ-=0mJFX9k4RFzA@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