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_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3e0f5f00b34b5bb08e98511bdb89dd31150abdef 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(+)
