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

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" <pg(at)bowt(dot)ie> wrote:
>On Thu, Nov 21, 2024 at 10:03 AM yuansong <yyuansong(at)126(dot)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