Andrew Sullivan wrote:
> On Tue, Jan 13, 2004 at 06:06:03PM -0500, Jack Orenstein wrote:
>
>>- Are any cases of corruption detected in the normal operation of
>>PostgreSQL?
>
>
> If this means, "Does the database usually check for corruption?" the
> answer is, "Not as a matter of course."
Do you mean that this happens in a few select situations? Or that
there are configuration flags that can be used to enable such checks?
> ...
>
>>- Are there any tools we can run to determine whether a database is
>>corrupt?
>
>
> This depends on the case. There is a utility called pgfsck floating
> around; it's dangerous, and for use where things are really totally
> hosed up so badly that you can't recover.
>
> The real question is, what have you been using that makes database
> corruption such a grave concern? If I had to worry that much about
> Postgres database corruption, I'd use something else.
The database is part of our product and we'd like it to be as
unobtrusive as possible. Our product has an admin console, but our
expectation is that it will be ignored most of the time. In general,
we'd rather kick off a rebuild of the database more often that might
really be necessary, if this meant that we could minimize the
involvement of an admin.
Database corruption is a concern for two reasons. First, if it ever
does occur, we have to be able to deal with the situation gracefully,
even if that means nothing beyond a clean shutdown of the
application. Second, we are struggling with the IDE vs. fsync issue,
that has come up on this mailing list. We definitely have to support
IDE drives, and we're trying to determine how to balance performance
against other concerns. If we do end up leaving IDE caching enabled,
then my understanding is that corruption is a real possibility, (or
have I drawn the wrong conclusion on this point?)
Jack Orenstein
