Re: corruption diag/recovery, pg_dump crash

From: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: corruption diag/recovery, pg_dump crash
Date: 2003-12-08 14:19:26
Message-ID: 200312080719.26586.pgsql@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)bluepolka(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Chris Travers 2003-12-08 14:53:16 Re: CREATE RULE problem/question requesting workaround
Previous Message Tino Wildenhain 2003-12-08 14:02:37 Re: UNICODE problem on 7.4 with COPY