Date: Sat, 08 May 2010 01:32:59 +0200
From: Bernd Helmle <mailings@oopsware.de>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	Andrew Dunstan <andrew@dunslane.net>
cc: pgsql-hackers@postgresql.org
Subject: Re: no universally correct setting for fsync
Message-ID: <A1EBC6E5100210B51612365E@amenophis>
In-Reply-To: <4BE3E205020000250003138F@gw.wicourts.gov>
References: <4BE3D3930200002500031382@gw.wicourts.gov>
	<4BE425F7.30804@dunslane.net>
	<4BE3E205020000250003138F@gw.wicourts.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--On 7. Mai 2010 09:48:53 -0500 Kevin Grittner 
<Kevin.Grittner@wicourts.gov> wrote:

> I think it goes beyond "tweaking" -- I think we should have a bald
> statement like "don't turn this off unless you're OK with losing the
> entire contents of the database cluster."  A brief listing of some
> cases where that is OK might be illustrative.
>

+1

> I never meant to suggest any statement in that section is factually
> wrong; it's just all too rosy, leading people to believe it's no big
> deal to turn it off.

I think one mistake in this paragraph is the passing mention of 
"performance". I've seen installations in the past with fsync=off only 
because the admin was pressured to get instantly "more speed" out of the 
database (think of "fast_mode=on"). In my opinion, phrases like 
"performance penalty" are misleading, if you need that setting in 99% of 
all use cases for reliable operation.

I've recently even started to wonder if the performance gain with fsync=off 
is still that large on modern hardware. While testing large migration 
procedures to a new version some time ago (on an admitedly fast storage) i 
forgot here and then to turn it off, without a significant degradation in 
performance.


-- 
Thanks

	Bernd