Re: BUG #14134: segmentation fault with large table with gist index

On Wed, May 11, 2016 at 12:37 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> The bug is in commit 35fcb1b3, which failed to initialize ssup_ctx.
> I'm surprised that it took this long for there to be trouble, because
> that commit doesn't initialize anything at all in the sortsupport
> object.

Here are simple steps to reproduce the bug:

postgres=# create table bug as select (now() - (current_date + i))
intv from generate_series(0,10000) i;
SELECT 10001
postgres=# set enable_indexonlyscan = off;
SET
postgres=# set enable_sort = off;
SET
postgres=# create extension btree_gist;
CREATE EXTENSION
postgres=# create index sortsupport_bug on bug using gist (intv);
CREATE INDEX
postgres=# SELECT * FROM bug ORDER BY intv <-> '1 days' LIMIT 10;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>

My previous analysis on why this occurred so infrequently as to only
see a problem report months after a stable release was wrong. This bug
only happens in narrow situations where a distance function exists
that is indexable by GiST, while that also lacks SortSupport. GiST
isn't doing anything with any other SortSupport attribute that lacks a
distance operator.

The lack of SortSupport will make SortSupport use a shim comparator,
which tries to use caller's memory context, which was found to be NULL
(since we palloc0()). So, this bug is fairly narrow in practice,
because you had to be using the distance operator for interval, which
looks like the only example of where this is possible.

Attached patch fixes the bug by initializing the SortSupport states used.

--
Peter Geoghegan