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

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Euler Taveira <euler(at)timbira(dot)com(dot)br>
Cc: yjh0502(at)gmail(dot)com, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14134: segmentation fault with large table with gist index
Date: 2016-05-11 19:56:38
Message-ID: CAM3SWZQ2nagtfpsQBgKzZrwweh2NodZTQxh96fp0VyJ7kwAvzA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2016-05-11 20:13:53 Re: BUG #14134: segmentation fault with large table with gist index
Previous Message Peter Geoghegan 2016-05-11 19:37:48 Re: BUG #14134: segmentation fault with large table with gist index