the read-only configuration variable <xref
   linkend="guc-data-checksums" /> by issuing the command <command>SHOW
   data_checksums</command>.
  </para>

  <para>
   When attempting to recover from page corruptions, it may be necessary to
   bypass the checksum protection. To do this, temporarily set the
   configuration parameter <xref linkend="guc-ignore-checksum-failure" />.
  </para>

  <sect2 id="checksums-offline-enable-disable">
   <title>Off-line Enabling of Checksums</title>

   <para>
    The <link linkend="app-pgchecksums"><application>pg_checksums</application></link>
    application can be used to enable or disable data checksums, as well as
    verify checksums, on an offline cluster.
   </para>

  </sect2>
 </sect1>

  <sect1 id="wal-intro">
   <title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>

   <indexterm zone="wal">
    <primary>WAL</primary>
   </indexterm>

   <indexterm>
    <primary>transaction log</primary>
    <see>WAL</see>
   </indexterm>

   <para>
    <firstterm>Write-Ahead Logging</firstterm> (<acronym>WAL</acronym>)
    is a standard method for ensuring data integrity.  A detailed
    description can be found in most (if not all) books about
    transaction processing. Briefly, <acronym>WAL</acronym>'s central
    concept is that changes to data files (where tables and indexes
    reside) must be written only after those changes have been logged,
    that is, after WAL records describing the changes have been flushed
    to permanent storage. If we follow this procedure, we do not need
    to flush data pages to disk on every transaction commit, because we
    know that in the event of a crash we will be able to recover the
    database using the log: any changes that have not been applied to
    the data pages can be redone from the WAL records.  (This is
    roll-forward recovery, also known as REDO.)
   </para>

   <tip>
    <para>
     Because <acronym>WAL</acronym> restores database file
     contents after a crash, journaled file systems are not necessary for
     reliable storage of the data files or WAL files.  In fact, journaling
     overhead can reduce performance, especially if journaling
     causes file system <emphasis>data</emphasis> to be flushed
     to disk.  Fortunately, data flushing during journaling can
     often be disabled with a file system mount option, e.g.,
     <literal>data=writeback</literal> on a Linux ext3 file system.
     Journaled file systems do improve boot speed after a crash.
    </para>
   </tip>


   <para>
    Using <acronym>WAL</acronym> results in a
    significantly reduced number of disk writes, because only the WAL
    file needs to be flushed to disk to guarantee that a transaction is
    committed, rather than every data file changed by the transaction.
    The WAL file is written sequentially,
    and so the cost of syncing the WAL is much less than the cost of
    flushing the data pages.  This is especially true for servers
    handling many small transactions touching different parts of the data
    store.  Furthermore, when the server is processing many small concurrent
    transactions, one <function>fsync</function> of the WAL file may
    suffice to commit many transactions.
   </para>

   <para>
    <acronym>WAL</acronym> also makes it possible to support on-line
    backup and point-in-time recovery, as described in <xref
    linkend="continuous-archiving"/>.  By archiving the WAL data we can support
    reverting to any time instant covered by the available WAL data:
    we simply install a prior physical backup of the database, and
    replay the WAL just as far as the desired time.  What's more,
    the physical backup doesn't have to be an instantaneous snapshot
    of the database state &mdash; if it is made over some period of time,
    then replaying the WAL for that period will fix any internal
    inconsistencies.
   </para>
  </sect1>

 <sect1 id="wal-async-commit">
  <title>Asynchronous Commit</title>

   <indexterm>