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 a power failure or system 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>
        Examples of safe circumstances for turning off
        <varname>fsync</varname> include the initial loading of a new
        database cluster from a backup file, using a database cluster
        for processing a batch of data after which the database
        will be thrown away and recreated,
        or for a read-only database clone which
        gets recreated frequently and is not used for failover.  High
        quality hardware alone is not a sufficient justification for
        turning off <varname>fsync</varname>.
       </para>

       <para>
        For reliable recovery when changing <varname>fsync</varname>
        off to on, it is necessary to force all modified buffers in the
        kernel to durable storage.  This can be done while the cluster
        is shutdown or while <varname>fsync</varname> is on by running <command>initdb
        --sync-only</command>, running <command>sync</command>, unmounting the
        file system, or rebooting the server.
       </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</filename>
        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>

     <varlistentry id="guc-synchronous-commit" xreflabel="synchronous_commit">
      <term><varname>synchronous_commit</varname> (<type>enum</type>)
      <indexterm>
       <primary><varname>synchronous_commit</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies how much WAL processing must complete before
        the database server returns a <quote>success</quote>
        indication to the client.  Valid values are
        <literal>remote_apply</literal>, <literal>on</literal>
        (the default), <literal>remote_write</literal>,
        <literal>local</literal>, and <literal>off</literal>.
       </para>

       <para>
        If <varname>synchronous_standby_names</varname> is empty,
        the only meaningful settings are <literal>on</literal> and
        <literal>off</literal>;  <literal>remote_apply</literal>,
        <literal>remote_write</literal> and <literal>local</literal>
        all provide the same local synchronization level
        as <literal>on</literal>.  The local behavior of all
        non-<literal>off</literal> modes is to wait for local flush of WAL
        to disk.  In <literal>off</literal> mode, there is no waiting,
        so there can be a delay between when success is reported to the
        client and when the transaction is later guaranteed to be safe
        against a server crash.  (The maximum
        delay is three times <xref linkend="guc-wal-writer-delay"/>.)  Unlike
        <xref linkend="guc-fsync"/>, setting this parameter to <literal>off</literal>
        does not create any risk of database inconsistency: an operating
        system or database crash might
        result in some recent allegedly-committed transactions being lost, but
        the database state will be just the same as if those transactions had
        been aborted cleanly.  So, turning <varname>synchronous_commit</varname>