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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-15 15:43:03
Message-ID: 2993260.1702654983@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Thu, Dec 14, 2023 at 10:43 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Probably better to clamp tuple width estimates to MaxAllocSize.
>> Anything larger would not correspond to reality anyhow.

> Fair point. How about the attached patch?

We'd need to hit at least build_joinrel_tlist too. Not sure
offhand whether this is enough to cover upper-relation tlists.

As far as the specifics go, is it enough to clamp once? I think
we'd either have to clamp after each addition, or change the
running-sum variables to double and clamp just before storing
into the final width field. The latter seems probably
less error-prone in the long run.

Also, given that we'll need at least three copies of the clamp
rule, I wonder if it's worth inventing a function comparable
to clamp_row_est().

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2023-12-16 09:19:22 Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
Previous Message Tom Lane 2023-12-15 15:30:40 Re: BUG #18247: Integer overflow leads to negative width