Scott Marlowe <scott.marlowe@xxxxxxxxx> writes: >> On Thu, Sep 23, 2010 at 2:17 PM, Tom Lane <tgl@xxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
