From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Lukasz Piskorz" <lpiskorz(at)ists(dot)pwr(dot)wroc(dot)pl> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Help - postgresql 7.0 and cannot read block 7959 of pg_log |
Date: | 2004-02-19 14:49:53 |
Message-ID: | 1832.1077202193@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"Lukasz Piskorz" <lpiskorz(at)ists(dot)pwr(dot)wroc(dot)pl> writes:
> When I check all tables only one (very important in my database) is
> corrupted:
> database=>select * from table;
> ERROR: cannot read block 7959 of pg_log: Success
This looks like something is trying to access the commit status of an
out-of-range transaction number, which is usually the first failure you
get when a row header has been corrupted. (In more recent PG versions,
you'd get a complaint about trying to access a nonexistent pg_clog
file.) The odds are that the corruption has damaged an entire page of
that table.
I'm afraid there's no question that you've lost some data. You might be
able to partially recover by zeroing out the broken page --- that would
at least let you dump the data in the remaining pages of the table.
See the mail list archives concerning methods for locating data
corruption more precisely.
> Could you help me? What can I do? Can I remove this table and restore from
> backup?
If you have a recent backup that might be the way to go.
> What do you think about software
> http://svana.org/kleptog/pgsql/pgfsck.html ?
I dunno if that works on versions as old as 7.0.
One thing you should definitely do as soon as you've extracted as much
data as you can is to update to some newer version. 7.0.* was a long
time and a lot of bug fixes ago.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Eduardo Leva | 2004-02-19 17:12:57 | WAL logs and segment files |
Previous Message | Tom Lane | 2004-02-19 14:30:14 | Re: ANALYZE crashes randomly |