Re: [HACKERS] Finding corrupt data

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

Browse pgsql-hackers by date

  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.