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

daveg <daveg@sonic.net>

From: David Gould <daveg@sonic.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <pg@bowt.ie>, 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-14T21:17:45Z
Lists: pgsql-bugs
On Wed, 12 Jul 2017 12:53:08 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> ... 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.

Not quite 50 years. In 1979 had the "pleasure" of working at Bechtel on a
Univac 1110. Univac 1100 seris are ones-complement (with both positive
and negative zero!) with 36 bit longs, 18 bit ints and depending on character
mode either 9 bit ASCII or 6 bit FIELDDATA chars. 

Not even one year. UNISYS are still marketing this architecture as the UNISYS
ClearPath IX series, you can order one today.

Apparently it is true in computing that nothing ever dies.

These were actually fascinatingly weird machines, almost everything is
different from what we are used to:

https://en.wikipedia.org/wiki/UNIVAC_1100/2200_series

Still, I think it is safe to wait until someone actually pays for a
postgresql port before considering ones-complement issues.

-dg

-- 
David Gould                                   daveg@sonic.net
If simplicity worked, the world would be overrun with insects.


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().