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" <p...@bowt.ie> wrote: >On Thu, Nov 21, 2024 at 10:03 AM yuansong <yyuans...@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
