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.

Reply via email to