sorry, I write something wrong。 I confirmed that there's an issue with prematurely ending the loop. When I enter the if (unlikely(result == 0 && key->scantid != NULL)) block, low = 2, mid = 4, and high = 4. At this point, the offset of insertstate->postingoff is obtained from the mid value, which is 4. However, the loop doesn't terminate and continues, causing the value of low to become 3. This is where I applied my fix based on master.
I aslo don't know how to fix the bug and commit it to the community master. At 2024-12-01 21:33:28, "Peter Geoghegan" <p...@bowt.ie> wrote: >On Sun, Dec 1, 2024 at 8:11 AM yuansong <yyuans...@126.com> wrote: >> the _bt_binsrch_insert function always returns low, but during the post list >> search, are there cases where low and mid are unequal? >> >> If so, this could potentially cause an offset in the subsequent >> _bt_insertonpg function. >> >> maybe we fix it like this ? > >Why? > >The "if (unlikely(result == 0 && key->scantid != NULL))" block is only >hit when we have an "exactly-equal" index tuple -- which means an >index tuple with a posting list covering a range of heap TIDs that our >scantid is covered by. There should be at most one index tuple like >this on any leaf page -- otherwise the index is corrupt. > >The hardening that I added for the posting list split stuff was added >to 13.4 and 13.5. You're running a very old point release (13.2), so >you weren't running a version of the server with that hardening. > >-- >Peter Geoghegan
0001-Fix-the-error-in-the-B-tree-binary-search-for-the-po.patch
Description: Binary data