Put "excludeOnly" GIN scan keys at the end of the scankey array. Commit 4b754d6c1 introduced the concept of an excludeOnly scan key, which cannot select matching index entries but can reject non-matching tuples, for example a tsquery such as '!term'. There are poorly-documented assumptions that such scan keys do not appear as the first scan key. ginNewScanKey did nothing to ensure that, however, with the result that certain GIN index searches could go into an infinite loop while apparently-equivalent queries with the clauses in a different order were fine.
Fix by teaching ginNewScanKey to place all excludeOnly scan keys after all not-excludeOnly ones. So far as we know at present, it might be sufficient to avoid the case where the very first scan key is excludeOnly; but I'm not very convinced that there aren't other dependencies on the ordering. Bug: #19031 Reported-by: Tim Wood <washwithc...@gmail.com> Author: Tom Lane <t...@sss.pgh.pa.us> Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org Backpatch-through: 13 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3a7a3eaaf9fe6d4669815de719300df124b869e1 Modified Files -------------- contrib/pg_trgm/expected/pg_trgm.out | 46 ++++++++++++++++++++++++++++++++++++ contrib/pg_trgm/sql/pg_trgm.sql | 8 +++++++ src/backend/access/gin/ginscan.c | 43 +++++++++++++++++++++++++++++++++ 3 files changed, 97 insertions(+)
