Message-ID: <bfff906f-300d-81ea-83b7-f2c93845e7f2@gmail.com>
Date: Fri, 16 Aug 2024 21: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: Remove dependence on integer wrapping
Content-Language: en-US
To: Nathan Bossart <nathandbossart@gmail.com>,
 Joseph Koshakow <koshy44@gmail.com>
Cc: jian he <jian.universality@gmail.com>,
 Heikki Linnakangas <hlinnaka@iki.fi>, Matthew Kim <matthewkmkim@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Andres Freund <andres@anarazel.de>
References: <ZrvUOkL19KHEH2sb@nathan> <ZrwfgNyDXy99NUOS@nathan>
 <875ad3ec-f216-487e-baad-cdbaf32c1fcf@iki.fi> <ZrznaJTIOPgSjEJ7@nathan>
 <CAAvxfHc2Smk92cJX4aUju1AdW_RpNN8csEj5rvf29b-YFHRmfQ@mail.gmail.com>
 <Zrz0Zv4PVFxieEii@nathan>
 <CACJufxH-uLR5SnnmVbGYj7Oy90zF_pYV3G_HxfbJ6Lu3XKGXxQ@mail.gmail.com>
 <Zr5M3KxOZlEZRZIN@nathan> <Zr50ZpSyrBx0EHfR@nathan>
 <CAAvxfHfkHS1n0+wMbtKwj6_GE6+aSJ9JjnsCOOdZPhTKRs-Yhw@mail.gmail.com>
 <Zr-DwBxep-IaayQF@nathan>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <Zr-DwBxep-IaayQF@nathan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/bfff906f-300d-81ea-83b7-f2c93845e7f2%40gmail.com>
Precedence: bulk

Hello Nathan and Joe,

16.08.2024 19:52, Nathan Bossart wrote:
> On Thu, Aug 15, 2024 at 10:49:46PM -0400, Joseph Koshakow wrote:
>> This updated version LGTM, I agree it's a good use of pg_abs_s32().
> Committed.

Thank you for working on that issue!

I've tried `make check` with CC=gcc-13 CPPFLAGS="-O0 -ftrapv" and got a
server crash:
2024-08-16 17:14:36.102 UTC postmaster[1982703] LOG:   (PID 1983867) was terminated by signal 6: Aborted
2024-08-16 17:14:36.102 UTC postmaster[1982703] DETAIL:  Failed process was running: select '[]'::jsonb ->> -2147483648;
with the stack trace
...
#5  0x0000556aec224a11 in __negvsi2 ()
#6  0x0000556aec046238 in jsonb_array_element_text (fcinfo=0x556aedd70240) at jsonfuncs.c:993
#7  0x0000556aebc90b68 in ExecInterpExpr (state=0x556aedd70160, econtext=0x556aedd706a0, isnull=0x7ffdf82211e4)
     at execExprInterp.c:765
...
(gdb) f 6
#6  0x0000556aec046238 in jsonb_array_element_text (fcinfo=0x556aedd70240) at jsonfuncs.c:993
993                     if (-element > nelements)
(gdb) p element
$1 = -2147483648

Sp it looks like jsonb_array_element_text() still needs the same
treatment as jsonb_array_element().

Moreover, I tried to use "-ftrapv" on 32-bit Debian and came across
another failure:
select '9223372036854775807'::int8 * 2147483648::int8;
server closed the connection unexpectedly
...
#4  0xb722226a in __GI_abort () at ./stdlib/abort.c:79
#5  0x004cb2e1 in __mulvdi3.cold ()
#6  0x00abe7ab in pg_mul_s64_overflow (a=9223372036854775807, b=2147483648, result=0xbff1da68)
     at ../../../../src/include/common/int.h:264
#7  0x00abfbff in int8mul (fcinfo=0x14d9d04) at int8.c:496
#8  0x00782675 in ExecInterpExpr (state=0x14d9c4c, econtext=0x14da15c, isnull=0xbff1dc3f) at execExprInterp.c:765

Whilst
select '9223372036854775807'::int8 * 2147483647::int8;
emits
ERROR:  bigint out of range

I've also discovered another trap-triggering case for a 64-bit platform:
select 1 union all select 1 union all select 1 union all select 1 union all
select 1 union all select 1 union all select 1 union all select 1 union all
select 1 union all select 1 union all select 1 union all select 1 union all
select 1 union all select 1 union all select 1 union all select 1 union all
select 1 union all select 1 union all select 1 union all select 1 union all
select 1 union all select 1 union all select 1 union all select 1 union all
select 1 union all select 1 union all select 1 union all select 1 union all
select 1 union all select 1 union all select 1;

server closed the connection unexpectedly
...
#5  0x00005576cfb1c9f3 in __negvdi2 ()
#6  0x00005576cf627c68 in bms_singleton_member (a=0x5576d09f7fb0) at bitmapset.c:691
#7  0x00005576cf72be0f in fix_append_rel_relids (root=0x5576d09df198, varno=31, subrelids=0x5576d09f7fb0)
     at prepjointree.c:3830
#8  0x00005576cf7278c2 in pull_up_simple_subquery (root=0x5576d09df198, jtnode=0x5576d09f7470, rte=0x5576d09de300,
     lowest_outer_join=0x0, containing_appendrel=0x5576d09f7368) at prepjointree.c:1277
...
(gdb) f 6
#6  0x00005576cf627c68 in bms_singleton_member (a=0x5576d09f7fb0) at bitmapset.c:691
691                             if (result >= 0 || HAS_MULTIPLE_ONES(w))
(gdb) p/x w
$1 = 0x8000000000000000

Best regards,
Alexander