From: Julien Rouhaud <rjuju123@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>
Cc: rekgrpth@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18247: Integer overflow leads to negative width
Date: Thu, 14 Dec 2023 11:57:40 +0100
Message-ID: <ZXrfpCxG5wglNVUe@jrouhaud> (raw)
In-Reply-To: <CAMbWs48nZf9XgAVpXbOnwGWWLnmoOZb51wnhkNW5xfz_PyOyCw@mail.gmail.com>
References: <18247-11ac477f02954422@postgresql.org>
<CAMbWs48nZf9XgAVpXbOnwGWWLnmoOZb51wnhkNW5xfz_PyOyCw@mail.gmail.com>
On Thu, Dec 14, 2023 at 06:34:44PM +0800, Richard Guo wrote:
> On Thu, Dec 14, 2023 at 5:29 PM PG Bug reporting form <
> noreply@postgresql.org> wrote:
>
> > EXPLAIN SELECT * FROM t;
> > QUERY PLAN
> > ------------------------------------------------------------
> > Seq Scan on t (cost=0.00..10.00 rows=1 width=-2113929008)
> > (1 row)
>
>
> Interesting. In an Assert-enabled build this query will cause the
> Assert failure in set_rel_width().
>
> Assert(tuple_width >= 0);
>
> Can we just error out when an overflow occurs?
I'm worried that it could have quite a broad impact, as the same problem could
easily arise in some more conventional cases, e.g. after joining some already
large relations. I'm sure that some people already hit that in production
without looking at explain plans, and wouldn't be happy to see it broken during
the next update.
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: pgsql-bugs@postgresql.org
Cc: rjuju123@gmail.com, guofenglinux@gmail.com, rekgrpth@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18247: Integer overflow leads to negative width
In-Reply-To: <ZXrfpCxG5wglNVUe@jrouhaud>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox