Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST
От | yuansong |
---|---|
Тема | Re:Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST |
Дата | |
Msg-id | 35b0b8dc.21.193509eef96.Coremail.yyuansong@126.com обсуждение исходный текст |
Ответ на | Re: backup server core when redo btree_xlog_insert that type is XLOG_BTREE_INSERT_POST (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
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@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
В списке pgsql-hackers по дате отправления: