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