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

RekGRpth <rekgrpth@gmail.com>

From: RekGRpth <rekgrpth@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Guo <guofenglinux@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2023-12-16T15:24:49Z
Lists: pgsql-bugs
If the value itself is not important, but the comparison of values is
important, then maybe it is possible to non-dimensionalize these
values?

пт, 15 дек. 2023 г. в 20:43, Tom Lane <tgl@sss.pgh.pa.us>:
>
> Richard Guo <guofenglinux@gmail.com> writes:
> > On Thu, Dec 14, 2023 at 10:43 PM Tom Lane <tgl@sss.pgh.pa.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



Commits

  1. Prevent integer overflow when forming tuple width estimates.

  2. compute_bitmap_pages' loop_count parameter should be double not int.