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

From: RekGRpth <rekgrpth(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18247: Integer overflow leads to negative width
Date: 2023-12-15 03:13:44
Message-ID: CAPgh2mKOawDQbmrtxXv_rOCSNAo4ByorMDGHdvy=Gs7ub734tw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

How bad would it be if, after overflowing, the width value was within
the allowed range?

пт, 15 дек. 2023 г. в 07:28, Richard Guo <guofenglinux(at)gmail(dot)com>:
>
>
> On Thu, Dec 14, 2023 at 10:43 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
>> > 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)
>>
>> > Can we just error out when an overflow occurs?
>>
>> Probably better to clamp tuple width estimates to MaxAllocSize.
>> Anything larger would not correspond to reality anyhow.
>
>
> Fair point. How about the attached patch?
>
> Thanks
> Richard

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-12-15 03:20:21 Re: BUG #18247: Integer overflow leads to negative width
Previous Message Richard Guo 2023-12-15 02:28:10 Re: BUG #18247: Integer overflow leads to negative width