On 1/16/26 19:03, Tomas Vondra wrote: > > On 1/15/26 06:08, Kirill Reshke wrote: >> ... >>>> >>>> I think tuplesort_begin_index_gin() has the same issue. It does this to >>>> look up the comparison function: >>>> >>>> /* >>>> * Look for an ordering for the index key data type, and then the sort >>>> * support function. >>>> */ >>>> typentry = lookup_type_cache(att->atttypid, TYPECACHE_LT_OPR); >>>> PrepareSortSupportFromOrderingOp(typentry->lt_opr, sortKey); >>>> >>>> That also looks up the key type's b-tree operator rather than the GIN >>>> opclass's compare function. >>>> >>> >>> Thanks for noticing this, I'll get this fixed next week. >>> >>> Funny, you noticed that almost exactly one year after I fixed the other >>> incorrect place in the patch ;-) >>> > > The attached 0001 should fix this. I'm wondering what kinds of issues it > might cause, and if we need to mention that in release notes. AFAICS it > would cause trouble if (a) there's no b-tree opclass, in which case the > tuplesort_begin_index_gin() errors out, or (b) the btree/gin opclasses > disagree on ordering (or rather equality). > > AFAIK we haven't heard anything about index builds failing on 18, and > with both btree/gin opclasses it seems unlikely they'd define equality > differently. Maybe I'm missing something. > >> >> >> I was looking at code coverage for GIN indexes [1] and noticed that >> Parallel GIN build is not covered in the regression test. Btree >> parallel build (_bt_begin_parallel function for example at[0]) is >> covered. I did not find any btree-parallel-build dedicated test, looks >> like this is covered by accident, from write_paralle, partition_prune >> and other regression tests. >> >> So, maybe add some tests here? Also, I wonder what regression sql file >> to use, or maybe create a new one. >> > > Fair point. Someone pinged me about this coverage issue a while back, > but it completely slipped my mind. 0002 tweaks two places in regression > tests to build the GIN index in parallel. Which for me seems to improve > the coverage quite a bit. It's not perfect, because it's still not a lot > of data, which means some code is impossible to hit (e.g. it'll not hit > trimming). >
Pushed both patches and backpatched to 18. Thanks! -- Tomas Vondra
