Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id F13BA632778
	for <pgsql-docs-postgresql.org@mail.postgresql.org>;
	Fri,  7 May 2010 21:18:09 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 71789-10 for
	<pgsql-docs-postgresql.org@mail.postgresql.org>;
	Sat,  8 May 2010 00:17:58 +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 6710B63383B
	for <pgsql-docs@postgresql.org>; Fri,  7 May 2010 21:17:58 -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 1OAXjt-0000Kn-Nt; Fri, 07 May 2010 17:17:56 -0700
Message-ID: <4BE4ADB1.4060509@agliodbs.com>
Date: Fri, 07 May 2010 17:17:53 -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: Tom Lane <tgl@sss.pgh.pa.us>
CC: 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> <4BE4AA33.7020700@agliodbs.com>
	<4335.1273277612@sss.pgh.pa.us>
In-Reply-To: <4335.1273277612@sss.pgh.pa.us>
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/5
X-Sequence-Number: 5502

On 5/7/10 5:13 PM, Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>> This is what I have to replace the current fsync entry in config.sgml.
> 
> s/unexpected shutdown/system crash/, perhaps.  The wording you have
> suggests that a forced Postgres stoppage produces a problem, which it
> doesn't.  It takes a failure at the OS level or below to cause a
> problem.

I actually meant "unexpected *system* shutdown", i.e. power-out.  A lot
of people think "crash" just means kernel dump, whereas a UPS failure or
tripped power cord is a lot more likely (except maybe on Windows).

Revised:

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


     <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 system shutdown or crash.  Thus it is only
advisable
        to turn off  <varname>fsync</varname> if you can easily recreate
        your entire database from external data.
       <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