Message-ID: <4CCE4A25.8050803@catalyst.net.nz>
Date: Mon, 01 Nov 2010 18:03:33 +1300
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10
MIME-Version: 1.0
To: pgsql-performance@postgresql.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>
In-Reply-To: <4CCDCAA3.4050805@2ndquadrant.com>
Content-Type: multipart/alternative;
	boundary="------------060507070406090804010201"

This is a multi-part message in MIME format.
--------------060507070406090804010201
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 01/11/10 08:59, Greg Smith wrote:
> Marti Raudsepp wrote:
>> Unless fdatasync is unsafe, I'd very much want to see it as the
>> default for 9.1 on Linux (I don't know about other platforms).  I
>> can't see any reasons why each write would need to be sync-ed if I
>> don't commit that often. Increasing wal_buffers probably has the same
>> effect wrt data safety.
>
> Writes only are sync'd out when you do a commit, or the database does 
> a checkpoint.
>
> This issue is a performance difference introduced by a recent change 
> to Linux.  open_datasync support was just added to Linux itself very 
> recently.  It may be more safe than fdatasync on your platform.  As 
> new code it may have bugs so that it doesn't really work at all under 
> heavy load.  No one has really run those tests yet.  See 
> http://wiki.postgresql.org/wiki/Reliable_Writes for some background, 
> and welcome to the fun of being an early adopter.  The warnings in the 
> tuning guide are there for a reason--you're in untested territory 
> now.  I haven't finished validating whether I consider 2.6.32 safe for 
> production use or not yet, and 2.6.36 is a solid year away from being 
> on my list for even considering it as a production database kernel.  
> You should proceed presuming that all writes are unreliable until 
> proven otherwise.
>

Greg,

Your reply is possibly a bit confusingly worded - Marti was suggesting 
that fdatasync be the default - so he wouldn't be a new adopter, since 
this call has been implemented in the kernel for ages. I guess you were 
wanting to stress that *open_datasync* is the new kid, so watch out to 
see if he bites...

Cheers

Mark

--------------060507070406090804010201
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 01/11/10 08:59, Greg Smith wrote:
<blockquote cite="mid:4CCDCAA3.4050805@2ndquadrant.com" type="cite">Marti
Raudsepp wrote:
  <br>
  <blockquote type="cite">Unless fdatasync is unsafe, I'd very much
want to see it as the
    <br>
default for 9.1 on Linux (I don't know about other platforms).  I
    <br>
can't see any reasons why each write would need to be sync-ed if I
    <br>
don't commit that often. Increasing wal_buffers probably has the same
    <br>
effect wrt data safety.
    <br>
  </blockquote>
  <br>
Writes only are sync'd out when you do a commit, or the database does a
checkpoint.
  <br>
  <br>
This issue is a performance difference introduced by a recent change to
Linux.  open_datasync support was just added to Linux itself very
recently.  It may be more safe than fdatasync on your platform.  As new
code it may have bugs so that it doesn't really work at all under heavy
load.  No one has really run those tests yet.  See
<a class="moz-txt-link-freetext" href="http://wiki.postgresql.org/wiki/Reliable_Writes">http://wiki.postgresql.org/wiki/Reliable_Writes</a> for some background,
and welcome to the fun of being an early adopter.  The warnings in the
tuning guide are there for a reason--you're in untested territory now. 
I haven't finished validating whether I consider 2.6.32 safe for
production use or not yet, and 2.6.36 is a solid year away from being
on my list for even considering it as a production database kernel. 
You should proceed presuming that all writes are unreliable until
proven otherwise.
  <br>
  <br>
</blockquote>
<font size="-1"><font face="Helvetica"><br>
Greg,<br>
<br>
Your reply is possibly a bit confusingly worded - Marti was suggesting
that fdatasync be the default - so he wouldn't be a new adopter, since
this call has been implemented in the kernel for ages. I guess you were
wanting to stress that *open_datasync* is the new kid, so watch out to
see if he bites...<br>
<br>
Cheers<br>
<br>
Mark<br>
</font></font>
</body>
</html>

--------------060507070406090804010201--