Re: Fwd: index corruption in PG 8.3.13

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

In response to

Responses

Browse pgsql-hackers by date

  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