Thread: pgsql: Fix bug where GIN scan keys were not initialized with gin_fuzzy_
pgsql: Fix bug where GIN scan keys were not initialized with gin_fuzzy_
From
Heikki Linnakangas
Date:
Fix bug where GIN scan keys were not initialized with gin_fuzzy_search_limit. 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. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/31ed42b9a3ea45a76cd78b29ee3b111b5ea0dbf3 Modified Files -------------- src/backend/access/gin/ginget.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)