From: | Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fwd: index corruption in PG 8.3.13 |
Date: | 2011-03-09 23:28:19 |
Message-ID: | AANLkTi=wwfFdB33zuFijDR5SzCos=EoEMViSoNPnAfDV@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2011-03-10 00:03:04 | Re: Native XML |
Previous Message | Mark Kirkwood | 2011-03-09 23:17:16 | Re: WIP - Add ability to constrain backend temporary file space |