Re: corruption diag/recovery, pg_dump crash
От | Ed L. |
---|---|
Тема | Re: corruption diag/recovery, pg_dump crash |
Дата | |
Msg-id | 200312080719.26586.pgsql@bluepolka.net обсуждение исходный текст |
Ответ на | corruption diag/recovery, pg_dump crash ("Ed L." <pgsql@bluepolka.net>) |
Список | 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 по дате отправления: