Message-ID: <4E421FC4.8030403@ringerc.id.au>
Date: Wed, 10 Aug 2011 14:05:56 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Sumeet Jauhar <sumeet.jauhar@gmail.com>
CC: pgsql-admin@postgresql.org
Subject: Re: Fwd: Suspected Postgres Datacorruption
References: 
 <CAKN1XtpsdHSJskgqFcNQGSFSLznKmE8D=SvM8wMr82GHmk6s0Q@mail.gmail.com>
	<CAKN1XtqtW7iWevGXJ0TBuix8Nm3r52fpbsy4bvV3zY69NjFpLQ@mail.gmail.com>
In-Reply-To: 
 <CAKN1XtqtW7iWevGXJ0TBuix8Nm3r52fpbsy4bvV3zY69NjFpLQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

On 4/08/2011 1:14 AM, Sumeet Jauhar wrote:

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

> A ) Isn’t Postgres database resilient enough to handle hardware system
> failure ? or it sometime results in a corrupt index for its tables ? I

You should *always* be able to pull the plug out of a box running Pg at 
any point and have it come up just fine. If you can't, it's a bug. They 
do turn up, but quite rarely and usually relating to odd corner cases in 
newly introduced features.

If you've done something like turn off fsync, of course, you've just 
told PostgreSQL "I don't care about my data, don't bother keeping it 
crash safe" and you get garbage if there's a system crash. But that's 
your choice to enable if your use case doesn't require data durability. 
You haven't done that, so this isn't the cause of your issue.

The only other known case (in a current version) where index corruption 
is expected after a crash is if you are using hash indexes. Hash indexes 
are NOT CRASH SAFE, as per the documentation, and WILL need to be 
reindexed after a crash. Don't use them unless you really know you need 
them (you don't).

Of course, if you're using 7.4.2 or something ancient, you're missing a 
lot of bug fixes, and some of them DID relate to data durability issues.

--
Craig Ringer