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
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 |