• Heikki Linnakangas's avatar
    Fix bug where GIN scan keys were not initialized with gin_fuzzy_search_limit. · 31ed42b9
    Heikki Linnakangas authored
    When gin_fuzzy_search_limit was used, we could jump out of startScan()
    without calling startScanKey(). That was harmless in 9.3 and below, because
    startScanKey()() didn't do anything interesting, but in 9.4 it initializes
    information needed for skipping entries (aka GIN fast scans), and you
    readily get a segfault if it's not done. Nevertheless, it was clearly wrong
    all along, so backpatch all the way to 9.1 where the early return was
    introduced.
    
    (AFAICS startScanKey() did nothing useful in 9.3 and below, because the
    fields it initialized were already initialized in ginFillScanKey(), but I
    don't dare to change that in a minor release. ginFillScanKey() is always
    called in gingetbitmap() even though there's a check there to see if the
    scan keys have already been initialized, because they never are; ginrescan()
    free's them.)
    
    In the passing, remove unnecessary if-check from the second inner loop in
    startScan(). We already check in the first loop that the condition is true
    for all entries.
    
    Reported by Olaf Gawenda, bug #12694, Backpatch to 9.1 and above, although
    AFAICS it causes a live bug only in 9.4.
    31ed42b9
ginget.c 49.3 KB