Re: Fwd: index corruption in PG 8.3.13
От | Nikhil Sontakke |
---|---|
Тема | Re: Fwd: index corruption in PG 8.3.13 |
Дата | |
Msg-id | AANLkTi=wwfFdB33zuFijDR5SzCos=EoEMViSoNPnAfDV@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fwd: index corruption in PG 8.3.13 (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>) |
Ответы |
Re: Fwd: index corruption in PG 8.3.13
Re: Fwd: index corruption in PG 8.3.13 |
Список | pgsql-hackers |
Hi, >>> Blocks 519 to 521 are DELETED. They do not have the LEAF flag set, >>> meaning they could be internal pages, but that is strange since ROOT >>> page is at level 1. Also importantly their next XID is set FrozenXid, >>> meaning VACUUM FULL was at play. Maybe due to deletes, we reduced the >>> hierarchy level or something? >> >> Hierarchy level is never reduced. >> >> I'll send you a perl program we wrote for a customer to check for >> strange issues in btrees. Please give it a spin; it may give you more >> clues. If you find additional checks to add, please let me know! >> > I tried to run Alvaro's perl script, but since the index chain is broken due to the zeroed out page pretty early on, it could not traverse it very well. While I rummage around the code more, does anyone have any theories on the below? "Other peculiarity in the index file is that we found a lot of zeroed out pages. Blocks from #279 to #518 are all completely zeroed out without any signs of even a page header. Any ideas on how we can get so many zeroed out blocks? Apart from the extend code path, I fail to see any other. And this is an unusually large number of zero pages" Comments appreciated. Regards, Nikhils
В списке pgsql-hackers по дате отправления: