> 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?
>
It is a few select situations and frankly I haven't had database corruption
because of PostgreSQL since the 7.1 days. I have had however database
corruption due to bad memory, and bad Linux kernels/filesystems.
> >>- Are there any tools we can run to determine whether a database is
> >>corrupt?
Typically PostgreSQL will tell you via an error message pointing to a
relation
id. Also if you perform regular vacuums if vacuum fails it will
typically tell you
where.
>
> > 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.
>
> 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?)
>
I think (at least personally) that you are placing a little too much
emphasis on
this problem. We have successfully done power plug tests over and over
and over with IDE drives and not had the issue come about.
Of course this entirely depends on many things, but that is what a UPS is
for.
Sincerely,
Joshua D. Drake
> Jack Orenstein
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
