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 по дате отправления: