Re: BUG #14134: segmentation fault with large table with gist index - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #14134: segmentation fault with large table with gist index
Date
Msg-id 560.1465142096@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #14134: segmentation fault with large table with gist index  (Peter Geoghegan <pg@heroku.com>)
Responses Re: BUG #14134: segmentation fault with large table with gist index  (Peter Geoghegan <pg@heroku.com>)
List pgsql-bugs
Peter Geoghegan <pg@heroku.com> writes:
> 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.

Pushed.  I added an explicit initialization of orderbysort->abbreviate,
because all the other callers of PrepareSortSupportFromOrderingOp make
a point of setting that.  Also a regression test.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Jeff Janes
Date:
Subject: Re: After upgrade to 9.5 space not being released
Next
From: Peter Geoghegan
Date:
Subject: Re: BUG #14134: segmentation fault with large table with gist index