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

From: Peter Geoghegan <[email-masked]>
Date: Thu, 21 Nov 2024 10:58:03 -0500

On Thu, Nov 21, 2024 at 10:03 AM yuansong <[email-masked]> 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

---

From: yuansong <[email-masked]>
Date: Fri, 22 Nov 2024 05:26:53 +0800 (CST)

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.