Content-Type: multipart/alternative;
 boundary="------------ZJgIoj8d2N2WXWsT00KatzUl"
Message-ID: <f5e15fe1-202d-1936-f47c-f0c69a936b72@gmail.com>
Date: Fri, 15 Dec 2023 09:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: BUG #18247: Integer overflow leads to negative width
Content-Language: en-US
To: Richard Guo <guofenglinux@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: rekgrpth@gmail.com, pgsql-bugs@lists.postgresql.org
References: <18247-11ac477f02954422@postgresql.org>
 <CAMbWs48nZf9XgAVpXbOnwGWWLnmoOZb51wnhkNW5xfz_PyOyCw@mail.gmail.com>
 <2781181.1702565025@sss.pgh.pa.us>
 <CAMbWs4_8+mtt5C8EXmfHa_Hs-OW6EhEz_XjhzBk8miwg2h65CQ@mail.gmail.com>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: 
 <CAMbWs4_8+mtt5C8EXmfHa_Hs-OW6EhEz_XjhzBk8miwg2h65CQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/f5e15fe1-202d-1936-f47c-f0c69a936b72%40gmail.com>
Precedence: bulk

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

Hello Richard,

15.12.2023 05:28, Richard Guo wrote:
>
> Fair point.  How about the attached patch?

Your patch looks good to me, but maybe you would find it suitable to fix in
passing one more integer overflow in costsize.c?

Concretely, the query:
CREATE TABLE t(id int PRIMARY KEY, i int);
EXPLAIN (VERBOSE)
UPDATE t SET i = ni FROM (SELECT g id, 1 ni FROM generate_series(1, 2147483648) g) s WHERE t.id = s.id;

when executed with ubsan-enabled build, gives:
costsize.c:1017:12: runtime error: 2.14748e+09 is outside the range of representable values of type 'int'
     #0 0x5603325818e0 in cost_bitmap_heap_scan .../src/backend/optimizer/path/costsize.c:1017:12
     #1 0x5603326cc519 in create_bitmap_heap_path .../src/backend/optimizer/util/pathnode.c:1065:2
...

Without ubsan enabled, the query:
EXPLAIN (VERBOSE)
UPDATE t SET i = ni FROM (SELECT g id, 1 ni FROM generate_series(1, 2147483648) g) s WHERE t.id = s.id;

executed visually similar to:
EXPLAIN (VERBOSE, ANALYZE)
UPDATE t SET i = ni FROM (SELECT g id, 1 ni FROM generate_series(1, 2147483647) g) s WHERE t.id = s.id;

but quite longer:
  Update on public.t  (cost=60.85..27122613.04 rows=0 width=0) (actual time=225204.159..225204.162 rows=0 loops=1)
vs
  Update on public.t  (cost=60.85..27122613.03 rows=0 width=0) (actual time=153015.851..153015.852 rows=0 loops=1)

Best regards,
Alexander
--------------ZJgIoj8d2N2WXWsT00KatzUl
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Richard,<br>
      <br>
      15.12.2023 05:28, Richard Guo wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMbWs4_8+mtt5C8EXmfHa_Hs-OW6EhEz_XjhzBk8miwg2h65CQ@mail.gmail.com"><br>
      <div dir="ltr">
        <div class="gmail_quote">
          <div>Fair point.  How about the attached patch?<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Your patch looks good to me, but maybe you would find it suitable to
    fix in<br>
    passing one more integer overflow in costsize.c?<br>
    <br>
    Concretely, the query:<br>
    CREATE TABLE t(id int PRIMARY KEY, i int);<br>
    EXPLAIN (VERBOSE)<br>
    UPDATE t SET i = ni FROM (SELECT g id, 1 ni FROM generate_series(1,
    2147483648) g) s WHERE t.id = s.id;<br>
    <br>
    when executed with ubsan-enabled build, gives:<br>
    costsize.c:1017:12: runtime error: 2.14748e+09 is outside the range
    of representable values of type 'int'<br>
        #0 0x5603325818e0 in cost_bitmap_heap_scan
    .../src/backend/optimizer/path/costsize.c:1017:12<br>
        #1 0x5603326cc519 in create_bitmap_heap_path
    .../src/backend/optimizer/util/pathnode.c:1065:2<br>
    ...<br>
    <br>
    Without ubsan enabled, the query:<br>
    EXPLAIN (VERBOSE)<br>
    UPDATE t SET i = ni FROM (SELECT g id, 1 ni FROM generate_series(1,
    2147483648) g) s WHERE t.id = s.id;<br>
    <br>
    executed visually similar to:<br>
    EXPLAIN (VERBOSE, ANALYZE)<br>
    UPDATE t SET i = ni FROM (SELECT g id, 1 ni FROM generate_series(1,
    2147483647) g) s WHERE t.id = s.id;<br>
    <br>
    but quite longer:<br>
     Update on public.t  (cost=60.85..27122613.04 rows=0 width=0)
    (actual time=225204.159..225204.162 rows=0 loops=1)<br>
    vs<br>
     Update on public.t  (cost=60.85..27122613.03 rows=0 width=0)
    (actual time=153015.851..153015.852 rows=0 loops=1)<br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------ZJgIoj8d2N2WXWsT00KatzUl--