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
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 |