Re: BUG #18247: Integer overflow leads to negative width
| От | RekGRpth |
|---|---|
| Тема | Re: BUG #18247: Integer overflow leads to negative width |
| Дата | |
| Msg-id | CAPgh2mKXdujnHmNO-Ty+rRHHtSeLnVU2qvkM-0dbBtmUWrGf+Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #18247: Integer overflow leads to negative width (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | 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
В списке pgsql-bugs по дате отправления: