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
-
Avoid integer overflow while sifting-up a heap in tuplesort.c.
- e439bbe9996f 9.4.13 landed
- e7213fe2bda8 9.5.8 landed
- 512f67c8d02c 10.0 landed
- 09c598898166 9.6.4 landed
-
Implement binary heap replace-top operation in a smarter way.
- 24598337c8d2 10.0 cited
-
Permit super-MaxAllocSize allocations with MemoryContextAllocHuge().
- 263865a48973 9.4.0 cited