| From: | Narek Galstyan <narek(dot)galstyan(at)enterprisedb(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, tgl(at)sss(dot)pgh(dot)pa(dot)us |
| Subject: | Fix btree_gist index corruption on bit and varbit types |
| Date: | 2026-11-05 18:05:42 |
| Message-ID: | CAHsn6_xPr5KOBeZcVO4wS209dBVXHNCv_Skb4t1o9xS3-WNvcg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi all,
See attached a regression test (0001) and fix (0002) for a
contrib/btree_gist index corruption.
btree_gist indexes on bit and VarBit types use an internal node
structure that is different from leaf note structure. So gbt_var_union()
has to always look for incoming leaf node and convert it to internal.
Current implementation copied its first entry into the union as is,
without checking if it is leaf. When the first entry is a leaf key, the
corresponding internal bound after a union is essentially corrupted.
Index scans can then return wrong results.
The fix makes sure that every entry (including the first) passes through
gbt_var_bin_union(), which already properly handles leaf2node
conversion.
Existing bit and varbit GiST indexes can return incomplete results and
should be reindexed.
I have found a few other issues in contrib/btree_gist relating to alignment,
wrong result near supported type range boundaries, etc.
I will clean those up and share all itemized test and fix patches in a
single separate
thread unless you suggest something else here.
Narek
--
| Attachment | Content-Type | Size |
|---|---|---|
| 0002-Fix-btree_gist-unions-of-bit-and-varbit-leaf-keys.patch | application/octet-stream | 1.9 KB |
| 0001-Add-a-test-for-btree_gist-bit-indexes-built-from-lea.patch | application/octet-stream | 3.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zakhar Pashkin | 2026-11-05 18:11:55 | Re: Print latency percentiles in pgbench |
| Previous Message | Ethan Tran | 2026-11-05 18:04:18 | Re: [PATCH]Fix planner's strictness check for JsonExpr |