| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| 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 16:04:40 |
| Message-ID: | 6517.1422547480@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> On 01/29/2015 05:26 PM, Tom Lane wrote:
>> Another, even simpler fix would be to just move the startScanKey()
>> call loop to before the "if (GinFuzzySearchLimit > 0)" block.
>> Is there a particular reason why it's a good idea to do things in
>> the current order? It almost looks like a patch application error
>> as it stands.
> The code in startScanKey() uses the predictNumberResult estimates, which
> the loop modifies, so it would change how that behaves.
Oh! Sorry, I'd missed looking at what the qsort comparator did.
> 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2015-01-29 17:58:43 | Re: BUG #12694: crash if the number of result rows is lower than gin_fuzzy_search_limit |
| Previous Message | Heikki Linnakangas | 2015-01-29 15:54:33 | Re: BUG #12694: crash if the number of result rows is lower than gin_fuzzy_search_limit |