"Ed L." <pgsql@bluepolka.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