Thread: pg_clog corruption?

pg_clog corruption?

From
"A Palmblad"
Date:
After trying a vacuum of a table, the following error has been occurring:
 
aers=# vacuum XXXXXX;
ERROR:  could not access status of transaction 4290052110
DETAIL:  could not open file "/usr/local/pgsql/data/pg_clog/0FFB": No such file or directory
This error will be repeated every time the vacuum is run.  We have some suspicions about the RAID controller in the server, but at the moment I'm wondering how to get around this error and complete the vacuum.  Zero_damaged_pages is on.
 
- Adam Palmblad

Re: pg_clog corruption?

From
Tom Lane
Date:
"A Palmblad" <adampalmblad@yahoo.ca> writes:
> After trying a vacuum of a table, the following error has been occurring:

> aers=3D# vacuum XXXXXX;
> ERROR:  could not access status of transaction 4290052110
> DETAIL:  could not open file "/usr/local/pgsql/data/pg_clog/0FFB": No such =
> file or directory

This isn't anything wrong with pg_clog; it's a trashed tuple header,
in particular a trashed transaction number.  It happens that the
transaction number is the first part of the header to be tested with
any great care when a new tuple is visited, so this sort of error is
a common symptom of localized data corruption in a table page.

> Zero_damaged_pages is on.

That only reacts to corrupted page headers, which you seemingly haven't
got (or at least, the page header is not so obviously bogus as to
trigger the damaged_pages code).

Your best bet is probably to track down which page contains the damage
and zero it out manually.  You can find recipes for doing this in the
list archives (try looking for threads that mention pg_filedump, which
is a useful tool when you're faced with this sort of thing).

            regards, tom lane