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