From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: rekgrpth@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18247: Integer overflow leads to negative width
In-reply-to: 
 <CAMbWs48nZf9XgAVpXbOnwGWWLnmoOZb51wnhkNW5xfz_PyOyCw@mail.gmail.com>
References: <18247-11ac477f02954422@postgresql.org>
 <CAMbWs48nZf9XgAVpXbOnwGWWLnmoOZb51wnhkNW5xfz_PyOyCw@mail.gmail.com>
Comments: In-reply-to Richard Guo <guofenglinux@gmail.com>
	message dated "Thu, 14 Dec 2023 18:34:44 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2781180.1702565025.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Thu, 14 Dec 2023 09:43:45 -0500
Message-ID: <2781181.1702565025@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2781181.1702565025%40sss.pgh.pa.us>
Precedence: bulk

Richard Guo <guofenglinux@gmail.com> writes:
> 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)

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

			regards, tom lane