Scott Marlowe <scott.marlowe@gmail.com> writes:
>> On Thu, Sep 23, 2010 at 2:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> If you can apply this patch:
>>> http://archives.postgresql.org/pgsql-committers/2010-08/msg00365.php
>>> it should tell you which index page is causing the problem. �Then
>>> please dump that page with pg_filedump and send it in.
> OK, got an error on it today. Looks like a corrupted index. Note
> that this is on a machine that was very well tested, but who knows, a
> single bit error could have occurred. pg_filedump attached.
Hm, I should've specified that -i -f options produce the most useful
output from pg_filedump :-(. It's pretty obvious that you've got 500+
bytes worth of seriously corrupted data there, but at least in this view
it's hard to tell if there's any clear pattern to the bad data.
I'd be inclined to suspect disk subsystem malfeasance not a RAM problem.
In particular I'm suspicious that the original corruption amounted to
exactly one 512-byte sector. If the index page wasn't full at the time,
it's possible that additional insertions could have occurred without
provoking obvious errors. That could have shifted and enlarged the
damaged area to what we see here, which looks to be 540 bytes starting
at page offset 552 (if I counted on my fingers correctly). I count
seven sane-looking line pointer items within the damaged-looking range,
which account for 7*4 = 28 bytes, so if those got inserted later then
there was exactly 512 bytes worth of damage initially. It's harder
to tell whether there were exactly ten insertions before the damaged
area to shift it up from offset 512 to offset 552, but given that the
other math comes out right I'm prepared to bet a nickle or two on this
theory.
regards, tom lane