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  (RekGRpth <rekgrpth@gmail.com>)
Re: BUG #18247: Integer overflow leads to negative width  (Richard Guo <guofenglinux@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #18247: Integer overflow leads to negative width
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends