Re: BUG #18247: Integer overflow leads to negative width

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: rekgrpth(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18247: Integer overflow leads to negative width
Date: 2023-12-14 10:57:40
Message-ID: ZXrfpCxG5wglNVUe@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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(at)postgresql(dot)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.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Laurenz Albe 2023-12-14 11:08:20 Re: BUG #18248: Expression is always zero
Previous Message Richard Guo 2023-12-14 10:34:44 Re: BUG #18247: Integer overflow leads to negative width