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