Re: Fwd: index corruption in PG 8.3.13 - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject Re: Fwd: index corruption in PG 8.3.13
Date
Msg-id AANLkTi=wwfFdB33zuFijDR5SzCos=EoEMViSoNPnAfDV@mail.gmail.com
Whole thread Raw
In response to Re: Fwd: index corruption in PG 8.3.13  (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>)
Responses Re: Fwd: index corruption in PG 8.3.13
Re: Fwd: index corruption in PG 8.3.13
List 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 by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: WIP - Add ability to constrain backend temporary file space
Next
From: Josh Berkus
Date:
Subject: Re: Native XML