Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bitoverflow
От | Heikki Linnakangas |
---|---|
Тема | Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bitoverflow |
Дата | |
Msg-id | 3de75af4-a49f-36d1-347f-f170693ce6f5@iki.fi обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bitoverflow (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow
Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow |
Список | pgsql-bugs |
On 07/06/2017 01:14 AM, Andres Freund wrote: > On 2017-07-05 18:03:56 -0400, Tom Lane wrote: >> I don't like s/int/int64/g as a fix for this. That loop is probably >> a hot spot, and this fix is going to be expensive on any machine where >> int64 isn't the native word width. How about something like this instead: >> >> - int j = 2 * i + 1; >> + int j; >> >> + if (unlikely(i > INT_MAX / 2)) >> + break; /* if j would overflow, we're done */ >> + j = 2 * i + 1; >> if (j >= n) >> break; > > Isn't an added conditional likely going to be more costly than the > s/32/64/ bit calculations on the majority of machines pg runs on? I'm > quite doubtful that it's worth catering for the few cases where that's > really slow. Another option to use "unsigned int", on the assumption that UINT_MAX >= INT_MAX * 2 + 1. And to eliminate that assumption, we can use (UINT_MAX - 1) / 2 as the maximum size of the memtuples array, rather than INT_MAX. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: