| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Brian Ristuccia <bristucc(at)sw(dot)starentnetworks(dot)com> |
| Cc: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: dumping tables from badly damaged db |
| Date: | 2003-10-31 19:45:57 |
| Message-ID: | 16557.1067629557@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Brian Ristuccia <bristucc(at)sw(dot)starentnetworks(dot)com> writes:
> The standalone backend errors out with:
> FATAL 1: _mdfd_getrelnfd: cannot open relation pg_trigger: No such file or
> directory
Well, if you can identify which of the lost+found files is pg_trigger,
you can move it back into place and then try again. (Look for trigger
names in the od -c dump...) All the system tables have fixed names
(relfilenode values) which you can determine by consulting another
database of the same PG version. pg_trigger is 16412 in 7.3, for
instance.
Lather, rinse, repeat until it comes up ...
> My week-old backups are starting to look more and more attractive.
I didn't say this was going to be painless.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff | 2003-10-31 19:47:37 | Re: SELECT COUNT(*)... returns 0 ROWS |
| Previous Message | Epps, Aaron M. | 2003-10-31 19:44:40 | Column References |