Content-Type: multipart/alternative;
 boundary="------------afVkH0QrvP4HmyIQKoCC3xpj"
Message-ID: <b718571e-acc6-4e64-a238-15076a6ad0f0@gmail.com>
Date: Sat, 14 Feb 2026 12:00:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19405: Assertion in eval_windowaggregates() fails due to
 integer overflow
To: Richard Guo <guofenglinux@gmail.com>, pgsql-bugs@lists.postgresql.org
References: <19405-1ecf025dda171555@postgresql.org>
 <CAMbWs4_GnG0NYnsBZJpHG-BLo28euD6VUx0WhFd4Ur6RaLr5WQ@mail.gmail.com>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <CAMbWs4_GnG0NYnsBZJpHG-BLo28euD6VUx0WhFd4Ur6RaLr5WQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/b718571e-acc6-4e64-a238-15076a6ad0f0%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------afVkH0QrvP4HmyIQKoCC3xpj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Richard,

14.02.2026 11:41, Richard Guo wrote:
> 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
--------------afVkH0QrvP4HmyIQKoCC3xpj
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Richard,<br>
      <br>
      14.02.2026 11:41, Richard Guo wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMbWs4_GnG0NYnsBZJpHG-BLo28euD6VUx0WhFd4Ur6RaLr5WQ@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">On Fri, Feb 13, 2026 at 7:09 PM PG Bug reporting form
<a class="moz-txt-link-rfc2396E" href="mailto:noreply@postgresql.org">&lt;noreply@postgresql.org&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">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;
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
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 &gt; winstate-&gt;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.
</pre>
    </blockquote>
    <br>
    Thank you for looking at this!<br>
    <br>
    The patch works for me, but I've just discovered one more similar
    anomaly:<br>
    SELECT SUM(i) OVER (ROWS BETWEEN 0x7fffffffffffffff FOLLOWING AND 1
    FOLLOWING), i FROM t;<br>
    <br>
    ERROR:  XX000: window frame head moved backward<br>
    LOCATION:  eval_windowaggregates, nodeWindowAgg.c:782<br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------afVkH0QrvP4HmyIQKoCC3xpj--