Horton

Re: BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Andres Freund <andres@anarazel.de>, Sergey Koposov <skoposov@cmu.edu>, "pgsql-bugs@postgresql.org" <pgsql-bugs@postgresql.org>
Date: 2017-07-12T16:53:08Z
Lists: pgsql-bugs 
Peter Geoghegan <pg@bowt.ie> writes:
> On Wed, Jul 12, 2017 at 9:20 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> Right, it's a hypothetical portability issue. The assumption we're making is
>> that UINT_MAX >= INT_MAX * 2 + 1. I'm not aware of any system where it's not
>> true, but I don't know what the C standards say about that.

> Intuitively, it seems very likely to be true, since two's complement
> arithmetic is already assumed by Postgres,

... right.  There haven't been any non-twos-complement machines in the
wild for probably 50 years, and even if there were, this would be *way*
down the list of problems you'd have to fix to get Postgres to run on
one of them.  I think a comment is plenty sufficient.

			regards, tom lane

Commits

  1. Avoid integer overflow while sifting-up a heap in tuplesort.c.

  2. Implement binary heap replace-top operation in a smarter way.

  3. Permit super-MaxAllocSize allocations with MemoryContextAllocHuge().