Message-ID: <4BE425F7.30804@dunslane.net>
Date: Fri, 07 May 2010 10:38:47 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.8.0.12) Gecko/20071019 Fedora/1.0.9-3.fc6 pango-text
	SeaMonkey/1.0.9
MIME-Version: 1.0
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
CC: pgsql-hackers@postgresql.org
Subject: Re: no universally correct setting for fsync
References: <4BE3D3930200002500031382@gw.wicourts.gov>
In-Reply-To: <4BE3D3930200002500031382@gw.wicourts.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Kevin Grittner wrote:
>  
> There are dire-sounding statements interspersed with:
>  
> | using fsync results in a performance penalty
>  
> | Due to the risks involved, there is no universally correct setting
> | for fsync.
>  
> | If you trust your operating system, your hardware, and your
> | utility company (or your battery backup), you can consider
> | disabling fsync.
>  
> Isn't this a little too rosy a picture to paint?
>  
>
>   

I think the critical question is really whether you are prepared to lose 
your database.

I have a customer who rotates databases in and out of line, and 
processes major updates on the out of line database. If they lose the 
database occasionally they are prepared to wear that risk for the 
performance gain they get from running with fsync off. It just means 
that they have to recover and so the inline database will get a bit 
staler than usual while they do.

So I think its true that there is no universally right answer. Maybe the 
criteria mentioned in the last para need tweaking some, though. It's not 
just a matter of trusting hardware etc. I have seen mishaps when idiots 
knock out power cords and the like. The unexpected does sometime happen, 
despite the best planning.

cheers

andrew