From: yuansong <yyuansong@126.com>
To: Peter Geoghegan <pg@bowt.ie>
To: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
To: pgsql-bugs@lists.postgresql.org
Subject: Re:Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST
Date: Wed, 27 Nov 2024 18:53:20 +0800 (CST)
Message-ID: <64d41b6e.9246.1936d410e18.Coremail.yyuansong@126.com> (raw)
In-Reply-To: <CAH2-Wznps8CcjbmRAmOMqv5K6pKZQxR0TTQLBhQAu+PxynmjBQ@mail.gmail.com>
References: <bdc9e08.a2c5.1934f3f42d0.Coremail.yyuansong@126.com>
<CAH2-Wznps8CcjbmRAmOMqv5K6pKZQxR0TTQLBhQAu+PxynmjBQ@mail.gmail.com>
we find crash reson
We have identified the cause of the crash: it was due to the XLOG_BTREE_INSERT_POST XLOG having an OffsetNumber offnum that was one less than what was stored in the index. I experimented with adding +1, and the index data remained normal in both cases. This issue is likely caused by concurrent operations on the B-tree, and upon reviewing the corresponding WAL logs, we found SPLIT_L and INSERT_LEAF operations on the same block before the crash. This might be a bug. I'm not sure if there's a related fix.
At 2024-11-21 23:58:03, "Peter Geoghegan" <pg@bowt.ie> wrote:
>On Thu, Nov 21, 2024 at 10:03 AM yuansong <yyuansong@126.com> wrote:
>> Should nhtids be less than or equal to IndexTupleSize(oposting)?
>> Why is nhtids larger than IndexTupleSize(oposting) ? I think there should be an error in the master host writing the wal log.
>> Does anyone know when this will happen?
>
>It'll happen whenever there is a certain kind of data corruption.
>
>There were complaints about issues like this in the past. But those
>complaints seem to have gone away when more hardening was added to the
>code that runs during original execution (not the REDO routine code,
>which can only do what it is told to do by the WAL record).
>
>You're using PostgreSQL 13.2, which is a very old point release that
>lacks this hardening -- the current 13 point release is 13.18, so
>you're missing a lot. Had you been on a later point release you'd very
>probably have still had the issue with corruption (which could be from
>bad hardware), but you likely would have avoided the problem with the
>REDO routine crashing like this.
>
>--
>Peter Geoghegan
Attachments:微信图片_20241127183704.jpg (image/jpeg, 2.0M) downloadview image
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, pgsql-bugs@lists.postgresql.org
Subject: Re:Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST
In-Reply-To: <64d41b6e.9246.1936d410e18.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