| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, <olaf(dot)gw(at)googlemail(dot)com>, <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #12694: crash if the number of result rows is lower than gin_fuzzy_search_limit |
| Date: | 2015-01-29 17:58:43 |
| Message-ID: | 54CA74D3.3090102@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 01/29/2015 06:04 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
>> On 01/29/2015 05:26 PM, Tom Lane wrote:
>> I'm not sure if
>> it would actually be better that way though; it's not clear to me how
>> the fuzzy search limit should interact with the fast scan code.
>
> Yeah, it might be better but it's not very clear what the implications
> are. Probably shouldn't touch that as part of an emergency bug fix.
Committed and backpatched a minimal fix.
For master and 9.4, I'm thinking of applying the attached. It makes it
clear that startScan() is not used to re-start a scan with existing scan
keys, but is always called on a newly initialized scan keys.
It also plugs the obvious leaking of the arrays. I'll look at the other
memory leaks separately, but this seems appropriate for 9.4.
- Heikki
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Fix-query-duration-memory-leak-with-GIN-rescans.patch | text/x-diff | 4.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2015-01-29 19:06:37 | Re: BUG #12670: Can't create postgis extension in single-user mode |
| Previous Message | Tom Lane | 2015-01-29 16:04:40 | Re: BUG #12694: crash if the number of result rows is lower than gin_fuzzy_search_limit |