Re: pg_clog corruption?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "A Palmblad" <adampalmblad(at)yahoo(dot)ca>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_clog corruption?
Date: 2004-04-15 23:27:46
Message-ID: 22204.1082071666@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"A Palmblad" <adampalmblad(at)yahoo(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Development - multi.art.studio 2004-04-15 23:39:36 Re: Filesystem vs. Postgres for images
Previous Message Tom Lane 2004-04-15 23:20:14 Re: Table Lock issue