| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Euler Taveira <euler(at)timbira(dot)com(dot)br>, Jihyun Yu <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-06-05 15:54:56 |
| Message-ID: | 560.1465142096@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Peter Geoghegan <pg(at)heroku(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2016-06-05 18:51:40 | Re: BUG #14134: segmentation fault with large table with gist index |
| Previous Message | Tom Lane | 2016-06-04 03:55:34 | Re: [BUGS] BUG #14155: bloom index error with unlogged table |