Suspected Postgres Data corruption

Our application is running on Postgres 7.4.X . I agree that this is a very old version of Postgres and we should have upgraded . The issue that we faced is that

1 . There was a system crash due to a hardware failure .

2 . When the system came up , we tried to insert a few records into the database . However at this point in time we saw that Postgres was taking a lot of CPU & memory .

Around 42% CPU consumption . This was a cause of concern .

3 . We re-indexed the database and it helped reduce the cpu & memory consumption .

My q开发者_运维问答uestion is

A ) Isn’t Postgres database resilient enough to handle hardware system failure ? or it sometime results in a corrupt index for its tables ? I read on the Postgres site that hardware failure can cause corrupt indexes . Besides this are there any other scenario which may result in such corruption .

B) If there has been improvement / enhancements done by Postgres regarding the way it handles corrupt indexes can you please pass me more information about the bug Id or some documentation on it ? Our application does not do any REINDEXING . I am in a dilemma if we should seriously incorporate it in our application .

Isn’t Postgres database resilient enough to handle hardware system failure ? or it sometime results in a corrupt index for its tables ? I read on the Postgres site that hardware failure can cause corrupt indexes .

What part of "hardware failure can cause corrupt indexes" did you not understand? (smile) I imagine the people that maintain the PostgreSQL web site know roughly what they're talking about.

A hardware failure--and especially a failure in the disk subsystem--can write garbage to the disk. A severe failure can physically damage the surface of a disk. A particularly spectacular hardware failure can redistribute pieces of your disk across several city blocks. (Explosion at a client site; they said some debris landed 20 miles away. I've learned not to rely much on dbms resiliency in such an event.)

There are a lot of ways to mitigate the risk of hardware failure. Most of them don't have anything to do with PostgreSQL, though. Redundant hardware--power supplies, NICs, RAID disk systems--battery backed cache (or disabling the write cache), server replication, cold and hot failover. None of these really have anything to do with PostgreSQL's own resiliency.

I don't know to what degree PostgreSQL diagnoses the state of its own indexes. If I have time later, I'll look at the PostgreSQL source code.