From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-15 02:28:10 |
Message-ID: | CAMbWs4_8+mtt5C8EXmfHa_Hs-OW6EhEz_XjhzBk8miwg2h65CQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Clamp-tuple_width-to-MaxAllocSize.patch | application/octet-stream | 1.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | RekGRpth | 2023-12-15 03:13:44 | Re: BUG #18247: Integer overflow leads to negative width |
Previous Message | Alexander Lakhin | 2023-12-14 17:17:17 | Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum |