public inbox for [email protected]  

help / color / mirror / Atom feed

From: yuansong <[email protected]>
To: Peter Geoghegan <[email protected]>
To: [email protected]
Subject: Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST
Date: Fri, 22 Nov 2024 05:26:53 +0800 (CST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAH2-Wznps8CcjbmRAmOMqv5K6pKZQxR0TTQLBhQAu+PxynmjBQ@mail.gmail.com>
References: <[email protected]>
	<CAH2-Wznps8CcjbmRAmOMqv5K6pKZQxR0TTQLBhQAu+PxynmjBQ@mail.gmail.com>

There may be something wrong with my previous description, "Should nhtids be less than or equal to IndexTupleSize(oposting)?

Why is nhtids larger than IndexTupleSize(oposting) " Here nhtids should be nmovebytes.

It is normal whether nhtids is larger than IndexTupleSize(oposting) or smaller than IndexTupleSize(oposting).

Should nmovebytes be smaller than IndexTupleSize(oposting)?




I checked the latest code of the master branch btree（backend\access\nbtree） and did not find any related fixes. 
This is also a low-probability event and is difficult to reproduce.

At 2024-11-21 23:58:03, "Peter Geoghegan" <[email protected]> wrote:
>On Thu, Nov 21, 2024 at 10:03 AM yuansong <[email protected]> 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

view thread (3+ messages)

reply

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: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox