| From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
|---|---|
| To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | GBNSCHBACH <GBNSCHBACH(at)aol(dot)com>, Postgres Hackers List <hackers(at)postgresql(dot)org> |
| Subject: | Re: [QUESTIONS] Basic table repair info. |
| Date: | 1998-03-11 03:45:51 |
| Message-ID: | 350608EF.97DAD450@alumni.caltech.edu |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > I'd like to know what are the table repair tools. I examined a table with
> > od -c
> > and boy, that does not look like what I put in. So other than good old
> > fashioned backups, how do you rebuild a corrupted file ?
> > Just wonderin'
> We don't need no sinking repair tools. :-)
> Actually, we very rarely hear about any corruption problems, so there
> are no repair tools.
Well, I've been wondering the same thing. I guess no one has been caught badly
enough to write the tools. It seems like one project could be to write a "recover
mode" into the backend, which would allow pg_dump to run to completion even though
a table is damaged. Would need a command line switch (or an SQL command) and then
some checks in the backend to return gracefully rather than throw an error and
quit.
- Tom
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas G. Lockhart | 1998-03-11 04:20:08 | Function call problems with BETWEEN |
| Previous Message | Thomas G. Lockhart | 1998-03-11 03:06:09 | Re: [HACKERS] postgres/alpha problems |