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 CAM3SWZTNLkiXN8P93C_CG17uECnopA-9JuMrkJbe7LXeWR5SXg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #14134: segmentation fault with large table with gist index  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Sun, Jun 5, 2016 at 8:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Thanks.

It hardly matters, but this bug did not occur because interval is
pass-by-reference (I withdrew my previous remarks on typbyval-ness
being a factor here). As it happens, the built-in pass-by-value types
almost all have SortSupport for as long there has been a
sortsupport.h, but that's not automatically true. The shim code path
would still be taken and would still dereference a NULL memory context
pointer if there was an affected type. (A pass-by-value type with a
distance operator usable by GiST, but no SortSupport, used in the same
way as the test case shows.)


--
Peter Geoghegan

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #14134: segmentation fault with large table with gist index
Next
From: Tomasz Ostrowski
Date:
Subject: Routine analyze of single column prevents standard autoanalyze from running at all