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

From Peter Geoghegan
Subject Re: BUG #14134: segmentation fault with large table with gist index
Date
Msg-id CAM3SWZQ2nagtfpsQBgKzZrwweh2NodZTQxh96fp0VyJ7kwAvzA@mail.gmail.com
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
List pgsql-bugs
On Wed, May 11, 2016 at 12:37 PM, Peter Geoghegan <pg@heroku.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.

It makes some sense that it took this long, actually.

Consider that most types have SortSupport, and so will use their own
memory context if memory allocation is needed for nodeIndexScan.c's
new-to-9.5 sort-like merging involving SortSupport. The field
ssup_collation was also not correctly initialized, for example, but
the SortSupport was allocated with palloc0(), so any problems that
that causes for collatable types will be relatively subtle. According
to convention, we won't attempt allocation with the ssup_ctx "parent"
memory context (which is NULL here), or we won't allocate any memory
at all in the case of simple pass-by-value types like int4.

I'll look into a patch to fix this.

--
Peter Geoghegan

pgsql-bugs by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: BUG #14134: segmentation fault with large table with gist index
Next
From: Peter Geoghegan
Date:
Subject: Re: BUG #14134: segmentation fault with large table with gist index