Message-ID: <4CD472CC.80006@2ndquadrant.com>
Date: Fri, 05 Nov 2010 14:10:36 -0700
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Andres Freund <andres@anarazel.de>
CC: pgsql-performance@postgresql.org, Marti Raudsepp <marti@juffo.org>
Subject: Re: Defaulting wal_sync_method to fdatasync on Linux for
 9.1?
References: <AANLkTi=n3zxiLNFhbpiN=JPQPwB=BhXf9iepw1KOEs8U@mail.gmail.com>
	<4CCDCAA3.4050805@2ndquadrant.com>
	<201011010010.28724.andres@anarazel.de>
In-Reply-To: <201011010010.28724.andres@anarazel.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Andres Freund wrote:
> On Sunday 31 October 2010 20:59:31 Greg Smith wrote:
>   
>> Writes only are sync'd out when you do a commit, or the database does a 
>> checkpoint.
>>     
> Hm?  WAL is written out to disk after an the space provided by wal_buffers(def 
> 8) * XLOG_BLCKSZ (def 8192) is used. The default is 64kb which you reach 
> pretty quickly - especially after a checkpoint.

Fair enough; I'm so used to bumping wal_buffers up to 16MB nowadays that 
I forget sometimes that people actually run with the default where this 
becomes an important consideration.


> Not having a real O_DSYNC on linux until recently makes it even more dubious 
> to have it as a default...
>   

If Linux is now defining O_DSYNC, and it's buggy, that's going to break 
more software than just PostgreSQL.  It wasn't defined before because it 
didn't work.  If the kernel developers have made changes to claim it's 
working now, but it doesn't really, I would think they'd consider any 
reports of actual bugs here as important to fix.  There's only so much 
the database can do in the face of incorrect information reported by the 
operating system.

Anyway, I haven't actually seen reports that proves there's any problem 
here, I was just pointing out that we haven't seen any positive reports 
about database stress testing on these kernel versions yet either.  The 
changes here are theoretically the right ones, and defaulting to safe 
writes that flush out write caches is a long-term good thing.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books