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
-
Prevent integer overflow when forming tuple width estimates.
- 7e1ce2b3de16 17.0 landed
-
compute_bitmap_pages' loop_count parameter should be double not int.
- 8b965c549dc8 17.0 landed