id="guc-wal-sync-method" xreflabel="wal_sync_method">
      <term><varname>wal_sync_method</varname> (<type>enum</type>)
      <indexterm>
       <primary><varname>wal_sync_method</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Method used for forcing WAL updates out to disk.
        If <varname>fsync</varname> is off then this setting is irrelevant,
        since WAL file updates will not be forced out at all.
        Possible values are:
       </para>
       <itemizedlist>
        <listitem>
        <para>
         <literal>open_datasync</literal> (write WAL files with <function>open()</function> option <symbol>O_DSYNC</symbol>)
        </para>
        </listitem>
        <listitem>
        <para>
         <literal>fdatasync</literal> (call <function>fdatasync()</function> at each commit)
        </para>
        </listitem>
        <listitem>
        <para>
         <literal>fsync</literal> (call <function>fsync()</function> at each commit)
        </para>
        </listitem>
        <listitem>
        <para>
         <literal>fsync_writethrough</literal> (call <function>fsync()</function> at each commit, forcing write-through of any disk write cache)
        </para>
        </listitem>
        <listitem>
        <para>
         <literal>open_sync</literal> (write WAL files with <function>open()</function> option <symbol>O_SYNC</symbol>)
        </para>
        </listitem>
       </itemizedlist>
       <para>
        Not all of these choices are available on all platforms.
        The default is the first method in the above list that is supported
        by the platform, except that <literal>fdatasync</literal> is the default on
        Linux and FreeBSD.  The default is not necessarily ideal; it might be
        necessary to change this setting or other aspects of your system
        configuration in order to create a crash-safe configuration or
        achieve optimal performance.
        These aspects are discussed in <xref linkend="wal-reliability"/>.
        This parameter can only be set in the <filename>postgresql.conf</filename>
        file or on the server command line.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-full-page-writes" xreflabel="full_page_writes">
      <term><varname>full_page_writes</varname> (<type>boolean</type>)
      <indexterm>
       <primary><varname>full_page_writes</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        When this parameter is on, the <productname>PostgreSQL</productname> server
        writes the entire content of each disk page to WAL during the
        first modification of that page after a checkpoint.
        This is needed because
        a page write that is in process during an operating system crash might
        be only partially completed, leading to an on-disk page
        that contains a mix of old and new data.  The row-level change data
        normally stored in WAL will not be enough to completely restore
        such a page during post-crash recovery.  Storing the full page image
        guarantees that the page can be correctly restored, but at the price
        of increasing the amount of data that must be written to WAL.
        (Because WAL replay always starts from a checkpoint, it is sufficient
        to do this during the first change of each page after a checkpoint.
        Therefore, one way to reduce the cost of full-page writes is to
        increase the checkpoint interval parameters.)
       </para>

       <para>
        Turning this parameter off speeds normal operation, but
        might lead to either unrecoverable data corruption, or silent
        data corruption, after a system failure. The risks are similar to turning off
        <varname>fsync</varname>, though smaller, and it should be turned off
        only based on the same circumstances recommended for that parameter.