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

Thank you very much for Peter Geoghegan's help. The issue has been resolved for some time now. It was indeed caused by corrupted index data, which resulted from collation differences between the hosts before and after the migration. Although the collation names were consistent, the differing glibc versions on the servers led to collation discrepancies, which caused the index sorting to become chaotic.

However, I noticed that the values of insertstate->postingoff are a bit disordered. In _bt_binsrch_posting, when if (!BTreeTupleIsPosting(itup)) return 0; is encountered, the normal search return value low starts from 0. In theory, there could also be a situation where the return value is 0. Therefore, it might be worth considering initializing or using non-PostList values as -1, and using -2 to represent ItemIdIsDead. Any other valid values should be greater than 0.

Additionally, I don’t think it's a good implementation for _bt_binsrch_insert to continue searching after finding the correct postingoff using binary search. The current approach is confusing and inefficient. Moreover, the idea of continuing the search to check if another postingoff exists in order to trigger an error seems to have minimal impact, as it only detects certain cases. This results in a function doing unrelated tasks. If such index anomalies need to be checked, it would be better to do so using external tools rather than checking during the core search process. The theory of single responsibility for a function。 If you agree with this proposal, I can try to implement the related fix later.