Re:Re: Re:Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST

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" <pg(at)bowt(dot)ie> wrote:
>On Sun, Dec 1, 2024 at 8:11 AM yuansong <yyuansong(at)126(dot)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