From: Gregory Stark <stark@enterprisedb.com>
To: "Dimitri" <dimitrik.fr@gmail.com>
Cc: "Heikki Linnakangas" <heikki@enterprisedb.com>,
	"PostgreSQL Performance" <pgsql-performance@postgresql.org>
Subject: Re: Filesystem Direct I/O and WAL sync option
In-Reply-To: <5482c80a0707030826v38c59870ib90599ba43337e72@mail.gmail.com>
	(dimitrik.fr@gmail.com's message of "Tue, 3 Jul 2007 17:26:55 +0200")
Organization: EnterpriseDB
References: <5482c80a0707030754o740c82b6s4598dc668720d014@mail.gmail.com>
	<468A65F5.8020800@enterprisedb.com>
	<5482c80a0707030826v38c59870ib90599ba43337e72@mail.gmail.com>
Date: Wed, 04 Jul 2007 02:13:02 +0100
Message-ID: <87lkdx0y5d.fsf@oxford.xeocode.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


"Dimitri" <dimitrik.fr@gmail.com> writes:

> Yes, disk drives are also having cache disabled or having cache on
> controllers and battery protected (in case of more  high-level
> storage) - but is it enough to expect data consistency?... (I was
> surprised about checkpoint sync, but does it always calls write()
> anyway? because in this way it should work without fsync)...

Well if everything is mounted in sync mode then I suppose you have the same
guarantee as if fsync were called after every single write. If that's true
then surely that's at least as good. I'm curious how it performs though.

Actually it seems like in that configuration fsync should be basically
zero-cost. In other words, you should be able to leave fsync=on and get the
same performance (whatever that is) and not have to worry about any risks.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com