Re: corruption diag/recovery, pg_dump crash

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: corruption diag/recovery, pg_dump crash
Date: 2003-12-06 23:43:29
Message-ID: 16479.1070754209@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Ed L." <pgsql(at)bluepolka(dot)net> writes:
> Here's the pg_dump output, edited to=20
> protect the guilty:

> pg_dump: PANIC: open of .../data/pg_clog/04E5 failed: No such file or=20
> directory

Given that this is far away from the range of valid clog segment names,
it seems safe to say that it's a symptom of a corrupted tuple header
(specifically, a whacked-out transaction ID number in some tuple
header).

You could probably track down the bad row (if there's only one or a few)
by expedients like seeing how far "SELECT ... FROM sometable LIMIT n"
will go without crashing. Once you have identified where the bad row is
located, you could try to repair it, or just zero out the whole page if
you're willing to lose the other rows on the same page. I would be
interested to see a pg_filedump dump of the corrupted page, if you go as
far as finding it.

(There are previous discussions of coping with corrupted data in the
mailing list archives. Searching for references to pg_filedump should
turn up some useful threads.)

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2003-12-06 23:45:12 Re: update time zone in timestamps
Previous Message Jochem van Dieten 2003-12-06 23:37:04 functions/operators with 2 sets as arguments