Re: BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Sergey Koposov <skoposov@cmu.edu>,
"pgsql-bugs@postgresql.org" <pgsql-bugs@postgresql.org>
Date: 2017-07-12T16:48:29Z
Lists: pgsql-bugs
On Wed, Jul 12, 2017 at 9:20 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: >> Uh ... what assumption? That's certainly true on any twos-complement >> machine. Besides, if you're worried about hypothetical portability >> issues, ... > > > 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, and addition and multiplication work the same way at the instruction level for unsigned and signed (two's complement) integers. In order for this to break, int and unsigned int would have to have different widths. > Well, you could do Min(INT_MAX, (UINT_MAX - 1 / 2). Or just add a > StaticAssertion for it. Or just note in a comment that we're making that > assumption. I like the idea of a StaticAssertion(). -- Peter Geoghegan
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