Date: Thu, 14 May 2015 11:32:12 -0400
From: Ravi Krishna <s.ravikrishna@aim.com>
To: tgl@sss.pgh.pa.us
Cc: pgsql-admin@postgresql.org
Message-Id: <14d530df35f-2108-30ce7@webstg-m03.mail.aol.com>
In-Reply-To: <20588.1431616292@sss.pgh.pa.us>
Subject: Re: WAL and O_DIRECT
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----=_Part_295587_591101141.1431617532766"
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

------=_Part_295587_591101141.1431617532766
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Aha that pretty much explains it. Yes we are using streaming replication.

However our DB2 folks are raising a concern that PG WAL writes may not be crash safe, unless we are using write back technology in SAN or SSD , which we are using.


-----Original Message-----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ravi Krishna <s.ravikrishna@aim.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>
Sent: Thu, May 14, 2015 11:11 am
Subject: Re: [ADMIN] WAL and O_DIRECT


Ravi Krishna <s.ravikrishna@aim.com> writes:
> Why is O_DIRECT not used,
despite the documentation mentioning otherwise?

You've not shown us all your
settings, but this comment in xlog.c might
explain it:

     * Optimize
writes by bypassing kernel cache with O_DIRECT when using
     * O_SYNC/O_FSYNC
and O_DSYNC.  But only if archiving and streaming are
     * disabled,
otherwise the archive command or walsender process will read
     * the WAL
soon after writing it, which is guaranteed to cause a physical
     * read if
we bypassed the kernel cache. We also skip the
     *
posix_fadvise(POSIX_FADV_DONTNEED) call in XLogFileClose() for the same
     *
reason.

			regards, tom lane

 
------=_Part_295587_591101141.1431617532766
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<font color='black' size='3' face='Verdana, Arial, Helvetica, sans-serif'>Aha that pretty much explains it. Yes we are using streaming replication.<br>
<br>
However our DB2 folks are raising a concern that PG WAL writes may not be crash safe, unless we are using write back technology in SAN or SSD , which we are using.<br>
<br>
<br>

<div style="font-family:arial,helvetica;font-size:10pt;color:black">-----Original Message-----<br>
From: Tom Lane &lt;tgl@sss.pgh.pa.us&gt;<br>
To: Ravi Krishna &lt;s.ravikrishna@aim.com&gt;<br>
Cc: pgsql-admin &lt;pgsql-admin@postgresql.org&gt;<br>
Sent: Thu, May 14, 2015 11:11 am<br>
Subject: Re: [ADMIN] WAL and O_DIRECT<br>
<br>


<div id="AOLMsgPart_1_e4aa7029-4356-4d1a-9ceb-fe62113990d6" style="margin: 0px;font-family: Tahoma, Verdana, Arial, Sans-Serif;font-size: 12px;color: #000;background-color: #fff;">

<pre style="font-size: 9pt;"><tt>Ravi Krishna &lt;<a href="mailto:s.ravikrishna@aim.com">s.ravikrishna@aim.com</a>&gt; writes:
&gt; Why is O_DIRECT not used,
despite the documentation mentioning otherwise?

You've not shown us all your
settings, but this comment in xlog.c might
explain it:

     * Optimize
writes by bypassing kernel cache with O_DIRECT when using
     * O_SYNC/O_FSYNC
and O_DSYNC.  But only if archiving and streaming are
     * disabled,
otherwise the archive command or walsender process will read
     * the WAL
soon after writing it, which is guaranteed to cause a physical
     * read if
we bypassed the kernel cache. We also skip the
     *
posix_fadvise(POSIX_FADV_DONTNEED) call in XLogFileClose() for the same
     *
reason.

			regards, tom lane
</tt></pre>
</div>
 <!-- end of AOLMsgPart_1_e4aa7029-4356-4d1a-9ceb-fe62113990d6 -->
</div>
</font>
------=_Part_295587_591101141.1431617532766--