Re: corruption diag/recovery, pg_dump crash - Mailing list pgsql-general

From Ed L.
Subject Re: corruption diag/recovery, pg_dump crash
Date
Msg-id 200312080719.26586.pgsql@bluepolka.net
Whole thread Raw
In response to corruption diag/recovery, pg_dump crash  ("Ed L." <pgsql@bluepolka.net>)
List pgsql-general
On Monday December 8 2003 6:55, Ed L. wrote:
> On Saturday December 6 2003 4:43, Tom Lane wrote:
> > "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).
>
> I moved PGDATA to a new system due to catastrophic hardware failures
> (media and data errors on RAID5 + operator error when a tech pulled a
> hotswap disk without failing the drive first).  Now I am finally getting
> a good look at the corruption (which appears to have moved around during
> the scp):
>
>  $ psql -c "\d misc"
> ERROR:  _mdfd_getrelnfd: cannot open relation pg_depend_depender_index:
> No such file or directory

And note this from .../data/base/28607376:

$ oid2name -d mydb -t pg_depend_depender_index
Oid of table pg_depend_depender_index from database "mydb":
---------------------------------
16622  = pg_depend_depender_index
$ ls -l 16622
ls: 16622: No such file or directory

Any clues as to first steps at recovery?  Recovering from backup is
unfortunately not a very viable option.

Ed


pgsql-general by date:

Previous
From: Tino Wildenhain
Date:
Subject: Re: UNICODE problem on 7.4 with COPY
Next
From: Chris Travers
Date:
Subject: Planner question regarding functions