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

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Gould <daveg@sonic.net>
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:45:30Z
Lists: pgsql-bugs
David Gould <daveg@sonic.net> writes:
> 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. 

Fun stuff.  Other than the ones-complement choice, this smells quite a bit
like the PDP-10 gear I used to use back when.

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

The recent models claim to be pure Intel though; if they're still
supporting the 1100 architecture, it must be through emulation.

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

Yeah.  I actually suspect that the weird word size would be a much bigger
headache for us than the ones-complement business.  The other small
problem is that as far as I could find, they never went past a 24-bit
address space, which would make for at most 64MB worth of memory (with
9-bit "bytes").  In principle you could probably run modern Postgres
with so little RAM, but it wouldn't be of any real use.

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