From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ed Loehr <ELOEHR(at)austin(dot)rr(dot)com> |
Cc: | Matthew Hagerty <matthew(at)venux(dot)net>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Finding corrupt data |
Date: | 1999-12-16 14:46:11 |
Message-ID: | 24469.945355571@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ed Loehr <ELOEHR(at)austin(dot)rr(dot)com> writes:
> One RDBMS I used had a utility called 'dbcheck' which did some sort of
> examination of indices, tables, etc., and issued an 'OK' or 'CORRUPT' for
> each examined object. Such a utility for pgsql might simply do some
> combination of SELECT * or COPY TO as you suggest above.
> Would it be reasonable to put such a tool make its way onto the todo list, in
> the absence of better alternatives?
What'd be really nice is some kind of 'fsck' for databases. But it'd be
a lot of work to write one, and more work to keep it up to date in the
face of continuing changes to the database representation.
One simpler thing that I'd like to see is for VACUUM to recreate indexes
from scratch instead of trying to compact them. This would provide a
very simple recovery procedure for corrupted indexes, and it seems
possible that it'd actually be faster than what VACUUM does now.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 1999-12-16 14:52:26 | Re: [HACKERS] SELECT ... AS ... names in WHERE/GROUP BY/HAVIN G |
Previous Message | Tom Lane | 1999-12-16 14:40:39 | Re: [HACKERS] Postmaster options, process spawning, logging, etc. |