pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Lookup the correct ordering for parallel GIN builds 2+ messages / 1 participants [nested] [flat]
* pgsql: Lookup the correct ordering for parallel GIN builds @ 2026-01-26 19:28 Tomas Vondra <tomas.vondra@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Tomas Vondra @ 2026-01-26 19:28 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Lookup the correct ordering for parallel GIN builds When building a tuplesort during parallel GIN builds, the function incorrectly looked up the default B-Tree operator, not the function associated with the GIN opclass (through GIN_COMPARE_PROC). Fixed by using the same logic as initGinState(), and the other place in parallel GIN builds. This could cause two types of issues. First, a data type might not have a B-Tree opclass, in which case the PrepareSortSupportFromOrderingOp() fails with an ERROR. Second, a data type might have both B-Tree and GIN opclasses, defining order/equality in different ways. This could lead to logical corruption in the index. Backpatch to 18, where parallel GIN builds were introduced. Discussion: https://postgr.es/m/73a28b94-43d5-4f77-b26e-0d642f6de777@iki.fi Reported-by: Heikki Linnakangas <hlinnaka@iki.fi> Backpatch-through: 18 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/db14dcdec69d560013b326ca3dea45b83a07ccd6 Modified Files -------------- src/backend/utils/sort/tuplesortvariants.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Lookup the correct ordering for parallel GIN builds @ 2026-01-26 19:28 Tomas Vondra <tomas.vondra@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Tomas Vondra @ 2026-01-26 19:28 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Lookup the correct ordering for parallel GIN builds When building a tuplesort during parallel GIN builds, the function incorrectly looked up the default B-Tree operator, not the function associated with the GIN opclass (through GIN_COMPARE_PROC). Fixed by using the same logic as initGinState(), and the other place in parallel GIN builds. This could cause two types of issues. First, a data type might not have a B-Tree opclass, in which case the PrepareSortSupportFromOrderingOp() fails with an ERROR. Second, a data type might have both B-Tree and GIN opclasses, defining order/equality in different ways. This could lead to logical corruption in the index. Backpatch to 18, where parallel GIN builds were introduced. Discussion: https://postgr.es/m/73a28b94-43d5-4f77-b26e-0d642f6de777@iki.fi Reported-by: Heikki Linnakangas <hlinnaka@iki.fi> Backpatch-through: 18 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/eee71a66cc860771837ed645a8dcf0ccffd735c6 Modified Files -------------- src/backend/utils/sort/tuplesortvariants.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-01-26 19:28 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-01-26 19:28 pgsql: Lookup the correct ordering for parallel GIN builds Tomas Vondra <tomas.vondra@postgresql.org> 2026-01-26 19:28 pgsql: Lookup the correct ordering for parallel GIN builds Tomas Vondra <tomas.vondra@postgresql.org>
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