Received: from maia.hub.org (maia-1.hub.org [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 7CC75632778
	for <pgsql-docs-postgresql.org@mail.postgresql.org>;
	Fri,  7 May 2010 21:03:56 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia,
	port 10024) with ESMTP id 20678-09 for
	<pgsql-docs-postgresql.org@mail.postgresql.org>;
	Sat,  8 May 2010 00:03:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from glacier.frostconsultingllc.com (glacier.frostconsultingllc.com
	[69.36.227.170])
	by mail.postgresql.org (Postfix) with ESMTP id 0F235632EB3
	for <pgsql-docs@postgresql.org>; Fri,  7 May 2010 21:03:05 -0300 (ADT)
Received: from dsl081-245-111.sfo1.dsl.speakeasy.net ([64.81.245.111]
	helo=Sidney-Stratton.local)
	by glacier.frostconsultingllc.com with esmtpsa
	(TLSv1:CAMELLIA256-SHA:256) (Exim 4.69)
	(envelope-from <josh@agliodbs.com>) id 1OAXVU-0000II-9p
	for pgsql-docs@postgresql.org; Fri, 07 May 2010 17:03:02 -0700
Message-ID: <4BE4AA33.7020700@agliodbs.com>
Date: Fri, 07 May 2010 17:02:59 -0700
From: Josh Berkus <josh@agliodbs.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
	rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
MIME-Version: 1.0
To: pgsql-docs@postgresql.org
Subject: Re: [HACKERS] no universally correct setting for fsync
References: <4BE3D3930200002500031382@gw.wicourts.gov>
	<4BE425F7.30804@dunslane.net>
	<4BE3E205020000250003138F@gw.wicourts.gov>
	<4BE4543D.8010309@agliodbs.com>
In-Reply-To: <4BE4543D.8010309@agliodbs.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9
X-Spam-Level: 
X-Archive-Number: 201005/3
X-Sequence-Number: 5500

Folks,

This is what I have to replace the current fsync entry in config.sgml.

I believe that the note about needing fsync for Warm Standby to work
correctly is true, but could someone verify it?

=========================

     <varlistentry id="guc-fsync" xreflabel="fsync">
      <indexterm>
       <primary><varname>fsync</> configuration parameter</primary>
      </indexterm>
      <term><varname>fsync</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        If this parameter is on, the <productname>PostgreSQL</> server
        will try to make sure that updates are physically written to
        disk, by issuing <function>fsync()</> system calls or various
        equivalent methods (see <xref linkend="guc-wal-sync-method">).
        This ensures that the database cluster can recover to a
        consistent state after an operating system or hardware crash.
       </para>

       <para>
        While turning off <varname>fsync</varname> is often a performance
        benefit, this can result in unrecoverable data corruption in the
event
        of an unexpected shutdown. Thus it is only advisable to turn off
        <varname>fsync</varname> if you can easily recreate
        your entire database from external data.  <varname>fsync</varname>
        must be on for WAL archiving to work correctly
        (see <xref linkend="continuous-archiving">).
       <para>

       <para>
        In many situations, turning off <xref
linkend="guc-synchronous-commit">
        for noncritical transactions can provide much of the potential
        performance benefit of turning off <varname>fsync</varname>, without
        the attendant risks of data corruption.
       </para>

       <para>
        <varname>fsync</varname> can only be set in the
<filename>postgresql.conf</>
        file or on the server command line.
        If you turn this parameter off, also consider turning off
        <xref linkend="guc-full-page-writes">.
       </para>
      </listitem>
     </varlistentry>

-- 
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com