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