From: yuansong <yyuansong@126.com>
To: Peter Geoghegan <pg@bowt.ie>
To: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re:Re: Re:Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST
Date: Sat, 11 Jan 2025 17:40:01 +0800 (CST)
Message-ID: <4ea3037a.2337.19454bc1a02.Coremail.yyuansong@126.com> (raw)
In-Reply-To: <CAH2-WznTAAbNJMCddUwxepgpicxhH6y55+zWSnOMiKOSLKY2TQ@mail.gmail.com>
References: <bdc9e08.a2c5.1934f3f42d0.Coremail.yyuansong@126.com>
<CAH2-Wznps8CcjbmRAmOMqv5K6pKZQxR0TTQLBhQAu+PxynmjBQ@mail.gmail.com>
<64d41b6e.9246.1936d410e18.Coremail.yyuansong@126.com>
<39b023e9.1ed0.19382575335.Coremail.yyuansong@126.com>
<CAH2-WznTAAbNJMCddUwxepgpicxhH6y55+zWSnOMiKOSLKY2TQ@mail.gmail.com>
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 instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: yyuansong@126.com, pg@bowt.ie, pgsql-hackers@lists.postgresql.org
Subject: Re:Re: Re:Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST
In-Reply-To: <4ea3037a.2337.19454bc1a02.Coremail.yyuansong@126.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox