Re: BUG #17245: Index corruption involving deduplicated entries
Вложения
В списке pgsql-bugs по дате отправления:
| От | Alvaro Herrera |
|---|---|
| Тема | Re: BUG #17245: Index corruption involving deduplicated entries |
| Дата | |
| Msg-id | 202110291850.cxcsg7j7ye6r@alvherre.pgsql обсуждение |
| Ответ на | Re: BUG #17245: Index corruption involving deduplicated entries (Kamigishi Rei <iijima.yun@koumakan.jp>) |
| Список | pgsql-bugs |
On 2021-Oct-29, Kamigishi Rei wrote: > The weird part about this is that the WAL archive does not seem to contain > any data for 157 and 158 above (in 1663/19243/274869 blk 17). The last two > entries are > > rmgr: Btree len (rec/tot): 53/ 4885, tx: 2085600, lsn: > 2/A0195AE0, prev 2/A01943F0, desc: INSERT_LEAF off 155, blkref #0: rel > 1663/19243/274869 blk 17 FPW > rmgr: Btree len (rec/tot): 72/ 72, tx: 2085602, lsn: > 2/A019DD30, prev 2/A019DCF0, desc: INSERT_LEAF off 156, blkref #0: rel > 1663/19243/274869 blk 17 > > The WAL file in data14/pg_wal does not have anything related to 157 and 158 > for this filenode/blk as well. Hmm, I don't remember precisely how index tuple removal works, but maybe these 157 and 158 entries existed previously and were truncated away. It might be useful to have a look at the page header in the page image contained in the FPW for 2/A0195AE0. pg_waldump doesn't do it, but I have this patch sitting around ... probably outdated, but it may be a useful starting point for somebody. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера