Re: BUG #12694: crash if the number of result rows is lower than gin_fuzzy_search_limit

On 01/29/2015 04:07 PM, Heikki Linnakangas wrote:
> The problem is in startScan() function:
>
>> if (GinFuzzySearchLimit > 0)
>> {
>> /*
>> * If all of keys more than threshold we will try to reduce result, we
>> * hope (and only hope, for intersection operation of array our
>> * supposition isn't true), that total result will not more than
>> * minimal predictNumberResult.
>> */
>>
>> for (i = 0; i < so->totalentries; i++)
>> if (so->entries[i]->predictNumberResult <= so->totalentries * GinFuzzySearchLimit)
>> return;
>>
>> for (i = 0; i < so->totalentries; i++)
>> if (so->entries[i]->predictNumberResult > so->totalentries * GinFuzzySearchLimit)
>> {
>> so->entries[i]->predictNumberResult /= so->totalentries;
>> so->entries[i]->reduceResult = TRUE;
>> }
>> }
>>
>> for (i = 0; i < so->nkeys; i++)
>> startScanKey(ginstate, so, so->keys + i);
>> }
>
> If the early return is taken, startScanKey() is not called, and many
> fields in the GinScanKey struct are left uninitialized. That causes the
> segfault later.
>
> This was not as big a problem before 9.4, because startScanKey() didn't
> do very much. It just reset a few fields, which in a new scan were reset
> already by ginNewScanKey(). But it is in fact possible to get an
> assertion failure on 9.3 too, if the plan contains a re-scan of GIN
> scan, and gin_fuzzy_search_limit is set. Attached is a script that does
> it. Not sure why, but I'm not seeing a segfault or assert failure on
> earlier branches. The plan of the segfaulting query looks identical
> between 9.2 and 9.3, so perhaps there have been some changes to the
> executor on how and when it calls rescan.

Never mind, I had some debugging code in place in my 9.3 branch that
caused the assertion failure. Still, it looks broken on 9.3 and below,
too. Either that, or GinNewKey() check in gingetbitmap is always true,
and the startScanKey() calls were unnecessary.

- Heikki