pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. 7+ messages / 1 participants [nested] [flat]
* pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. @ 2025-08-26 16:09 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-08-26 16:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <washwithcare@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19031-0638148643d25548@postgresql.org Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/327b7324d0715f5e1cdd3765f96a486c7b47e778 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(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. @ 2025-08-26 16:09 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-08-26 16:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <washwithcare@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19031-0638148643d25548@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(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. @ 2025-08-26 16:09 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-08-26 16:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <washwithcare@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19031-0638148643d25548@postgresql.org Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/456c6a05d9900816c94f28b750eda3f13a1049fb 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(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. @ 2025-08-26 16:09 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-08-26 16:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <washwithcare@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19031-0638148643d25548@postgresql.org Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d532069c391a2b50432f273052196496b7a61c64 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(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. @ 2025-08-26 16:09 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-08-26 16:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <washwithcare@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19031-0638148643d25548@postgresql.org Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/34249b3b58479e48d4f735289e34a13a8c0e8481 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(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. @ 2025-08-26 16:09 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-08-26 16:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <washwithcare@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19031-0638148643d25548@postgresql.org Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4a593043eee9b399ff6c1fc40862f820289786c1 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(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. @ 2025-08-26 16:09 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-08-26 16:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <washwithcare@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19031-0638148643d25548@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(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2025-08-26 16:09 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-08-26 16:09 pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. Tom Lane <tgl@sss.pgh.pa.us> 2025-08-26 16:09 pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. Tom Lane <tgl@sss.pgh.pa.us> 2025-08-26 16:09 pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. Tom Lane <tgl@sss.pgh.pa.us> 2025-08-26 16:09 pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. Tom Lane <tgl@sss.pgh.pa.us> 2025-08-26 16:09 pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. Tom Lane <tgl@sss.pgh.pa.us> 2025-08-26 16:09 pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. Tom Lane <tgl@sss.pgh.pa.us> 2025-08-26 16:09 pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox