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>
    <primary>synchronous commit</primary>
   </indexterm>

   <indexterm>
    <primary>asynchronous commit</primary>
   </indexterm>

  <para>
   <firstterm>Asynchronous commit</firstterm> is an option that allows transactions
   to complete more quickly, at the cost that the most recent transactions may
   be lost if the database should crash.  In many applications this is an
   acceptable trade-off.
  </para>

  <para>
   As described in the previous section, transaction commit is normally
   <firstterm>synchronous</firstterm>: the server waits for the transaction's
   <acronym>WAL</acronym> records to be flushed to permanent storage
   before returning a success indication to the client.  The client is
   therefore guaranteed that a transaction reported to be committed will
   be preserved, even in the event of a server crash immediately after.
   However, for short transactions this delay is a major component of the
   total transaction time.  Selecting asynchronous commit mode means that
   the server returns success as soon as the transaction is logically
   completed, before the <acronym>WAL</acronym> records it generated have
   actually made their way to disk.  This can provide a significant boost
   in throughput for small transactions.
  </para>

  <para>
   Asynchronous commit introduces the risk of data loss. There is a short
   time window between the report of transaction completion to the client
   and the time that the transaction is truly committed (that is, it is
   guaranteed not to be lost if the server crashes).  Thus asynchronous
   commit should not be used if the client will take external actions
   relying on the assumption that the transaction will be remembered.
   As an example, a bank would certainly not use asynchronous commit for
   a transaction recording an ATM's dispensing of cash.  But in many
   scenarios, such as event logging, there is no need for a strong
   guarantee of this kind.
  </para>

  <para>
   The risk that is taken by using asynchronous commit is of data loss,
   not data corruption.  If the database should crash, it will recover
   by replaying <acronym>WAL</acronym> up to the last record that was
   flushed.  The database will therefore be restored to a self-consistent
   state, but any transactions that were not yet flushed to disk will
   not be reflected in that state.  The net effect is therefore loss of
   the last few transactions.  Because the transactions are replayed in
   commit order, no inconsistency can be introduced &mdash; for example,
   if transaction B made changes relying on the effects of a previous
   transaction A, it is not possible for A's effects to be lost while B's
   effects are preserved.
  </para>

  <para>
   The user can select the commit mode of each transaction, so that
   it is possible to have both synchronous and asynchronous commit
   transactions running concurrently.  This allows flexible trade-offs
   between performance and certainty of transaction