Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow
От | Tom Lane |
---|---|
Тема | Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow |
Дата | |
Msg-id | 4817.1499874124@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bitoverflow (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow
|
Список | pgsql-bugs |
Heikki Linnakangas <hlinnaka@iki.fi> writes: > 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: > Another option to use "unsigned int", on the assumption that UINT_MAX >= > INT_MAX * 2 + 1. Ah, that seems like a fine idea. > And to eliminate that assumption, we can use (UINT_MAX > - 1) / 2 as the maximum size of the memtuples array, rather than INT_MAX. Uh ... what assumption? That's certainly true on any twos-complement machine. Besides, if you're worried about hypothetical portability issues, I'm not sure it's any better to assume that (UINT_MAX - 1) / 2 fits in a signed int. regards, tom lane -- 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 по дате отправления: