| From: | RekGRpth <rekgrpth(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Richard Guo <guofenglinux(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-16 15:24:49 |
| Message-ID: | CAPgh2mKXdujnHmNO-Ty+rRHHtSeLnVU2qvkM-0dbBtmUWrGf+Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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(at)sss(dot)pgh(dot)pa(dot)us>:
>
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2023-12-17 09:44:33 | BUG #18251: Incorrect DROP VIEW pg_catalog.* behavior |
| Previous Message | Tom Lane | 2023-12-16 15:19:18 | Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends |