portions of the database, and therefore a system
   crash (that is, a hardware or operating system crash, not a failure of
   <productname>PostgreSQL</productname> itself) could result in arbitrarily bad
   corruption of the database state.  In many scenarios, asynchronous
   commit provides most of the performance improvement that could be
   obtained by turning off <varname>fsync</varname>, but without the risk
   of data corruption.
  </para>

  <para>
   <xref linkend="guc-commit-delay"/> also sounds very similar to
   asynchronous commit, but it is actually a synchronous commit method
   (in fact, <varname>commit_delay</varname> is ignored during an
   asynchronous commit).  <varname>commit_delay</varname> causes a delay
   just before a transaction flushes <acronym>WAL</acronym> to disk, in
   the hope that a single flush executed by one such transaction can also
   serve other transactions committing at about the same time.  The
   setting can be thought of as a way of increasing the time window in
   which transactions can join a group about to participate in a single
   flush, to amortize the cost of the flush among multiple transactions.
  </para>

 </sect1>

 <sect1 id="wal-configuration">
  <title><acronym>WAL</acronym> Configuration</title>

  <para>
   There are several <acronym>WAL</acronym>-related configuration parameters that
   affect database performance. This section explains their use.
   Consult <xref linkend="runtime-config"/> for general information about
   setting server configuration parameters.
  </para>

  <para>
   <firstterm>Checkpoints</firstterm><indexterm><primary>checkpoint</primary></indexterm>
   are points in the sequence of transactions at which it is guaranteed
   that the heap and index data files have been updated with all
   information written before that checkpoint.  At checkpoint time, all
   dirty data pages are flushed to disk and a special checkpoint record is
   written to the WAL file.  (The change records were previously flushed
   to the <acronym>WAL</acronym> files.)
   In the event of a crash, the crash recovery procedure looks at the latest
   checkpoint record to determine the point in the WAL (known as the redo
   record) from which it should start the REDO operation.  Any changes made to
   data files before that point are guaranteed to be already on disk.
   Hence, after a checkpoint, WAL segments preceding the one containing
   the redo record are no longer needed and can be recycled or removed. (When
   <acronym>WAL</acronym> archiving is being done, the WAL segments must be
   archived before being recycled or removed.)
  </para>

  <para>
   The checkpoint requirement of flushing all dirty data pages to disk
   can cause a significant I/O load.  For this reason, checkpoint
   activity is throttled so that I/O begins at checkpoint start and completes
   before the next checkpoint is due to start; this minimizes performance
   degradation during checkpoints.
  </para>

  <para>
   The server's checkpointer process automatically performs
   a checkpoint every so often.  A checkpoint is begun every <xref
   linkend="guc-checkpoint-timeout"/> seconds, or if
   <xref linkend="guc-max-wal-size"/> is about to be exceeded,
   whichever comes first.
   The default settings are 5 minutes and 1 GB, respectively.
   If no WAL has been written since the previous checkpoint, new checkpoints
   will be skipped even if <varname>checkpoint_timeout</varname> has passed.
   (If WAL archiving is being used and you want to put a lower limit on how
   often files are archived in order to bound potential data loss, you should
   adjust the <xref linkend="guc-archive-timeout"/> parameter rather than the
   checkpoint parameters.)
   It is also possible to force a checkpoint by using the SQL
   command <command>CHECKPOINT</command>.
  </para>

  <para>
   Reducing <varname>checkpoint_timeout</varname> and/or
   <varname>max_wal_size</varname> causes checkpoints to occur
   more often. This