Neil Conway <neilc@samurai.com> writes:
> There is indeed no included repair utility for damaged files. There are
> a some tools for examining the Postgres on-disk format (like
> pg_filedump[1], and pgfsck[2]), which can be useful for crash recovery.
> There is also the zero_damaged_pages configuration parameter, which can
> be used to recover from page-level data corruption. Postgres could use
> better tools for this sort of low-level crash recovery, I agree. I think
> one reason for this is that such tools are rarely needed.
In my mind, the existence of an automated repair utility is an admission
that the software it's for is insufficiently robust. When we find a
repeatable data corruption scenario in Postgres, we *fix the bug*, we
don't make something to clean up after an unfixed bug. Comparison
point: thirty years ago, people wrote "fsck" utilities for their
non-robust filesystems, and hoped they'd get all their data back;
now they run journaling filesystems instead.
This is certainly not to claim that we don't have corruption problems;
we do. What we don't have are corruption problems that are predictable
enough to be repaired by automatic processes, nor ones widespread enough
to justify any great investment in such tools.
(But having said that, one use of REINDEX is as a repair utility for
broken indexes...)
regards, tom lane
