forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit37e0f13
committed
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, becausestartScanKey()() didn't do anything interesting, but in 9.4 it initializesinformation needed for skipping entries (aka GIN fast scans), and youreadily get a segfault if it's not done. Nevertheless, it was clearly wrongall along, so backpatch all the way to 9.1 where the early return wasintroduced.(AFAICS startScanKey() did nothing useful in 9.3 and below, because thefields it initialized were already initialized in ginFillScanKey(), but Idon't dare to change that in a minor release. ginFillScanKey() is alwayscalled in gingetbitmap() even though there's a check there to see if thescan 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 instartScan(). We already check in the first loop that the condition is truefor all entries.Reported by Olaf Gawenda, bug #12694, Backpatch to 9.1 and above, althoughAFAICS it causes a live bug only in 9.4.1 parent88b45aa commit37e0f13
1 file changed
+11
-4
lines changedLines changed: 11 additions & 4 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
511 | 511 |
| |
512 | 512 |
| |
513 | 513 |
| |
| 514 | + | |
514 | 515 |
| |
515 | 516 |
| |
| 517 | + | |
516 | 518 |
| |
517 |
| - | |
518 |
| - | |
519 |
| - | |
520 |
| - | |
| 519 | + | |
| 520 | + | |
| 521 | + | |
| 522 | + | |
| 523 | + | |
| 524 | + | |
| 525 | + | |
| 526 | + | |
521 | 527 |
| |
522 | 528 |
| |
523 | 529 |
| |
524 | 530 |
| |
| 531 | + | |
525 | 532 |
| |
526 | 533 |
| |
527 | 534 |
| |
|
0 commit comments
Comments
(0)