<!-- doc/src/sgml/wal.sgml -->

<chapter id="wal">
 <title>Reliability and the Write-Ahead Log</title>

 <para>
  This chapter explains how to control the reliability of
  <productname>PostgreSQL</productname>, including details about the
  Write-Ahead Log.
 </para>

 <sect1 id="wal-reliability">
  <title>Reliability</title>

  <para>
   Reliability is an important property of any serious database
   system, and <productname>PostgreSQL</productname> does everything possible to
   guarantee reliable operation. One aspect of reliable operation is
   that all data recorded by a committed transaction should be stored
   in a nonvolatile area that is safe from power loss, operating
   system failure, and hardware failure (except failure of the
   nonvolatile area itself, of course).  Successfully writing the data
   to the computer's permanent storage (disk drive or equivalent)
   ordinarily meets this requirement.  In fact, even if a computer is
   fatally damaged, if the disk drives survive they can be moved to
   another computer with similar hardware and all committed
   transactions will remain intact.
  </para>

  <para>
   While forcing data to the disk platters periodically might seem like
   a simple operation, it is not. Because disk drives are dramatically
   slower than main memory and CPUs, several layers of caching exist
   between the computer's main memory and the disk platters.
   First, there is the operating system's buffer cache, which caches
   frequently requested disk blocks and combines disk writes. Fortunately,
   all operating systems give applications a way to force writes from
   the buffer cache to disk, and <productname>PostgreSQL</productname> uses those
   features.  (See the <xref linkend="guc-wal-sync-method"/> parameter
   to adjust how this is done.)
  </para>

  <para>
   Next, there might be a cache in the disk drive controller; this is
   particularly common on <acronym>RAID</acronym> controller cards. Some of
   these caches are <firstterm>write-through</firstterm>, meaning writes are sent
   to the drive as soon as they arrive. Others are
   <firstterm>write-back</firstterm>, meaning data is sent to the drive at
   some later time. Such caches can be a reliability hazard because the
   memory in the disk controller cache is volatile, and will lose its
   contents in a power failure.  Better controller cards have
   <firstterm>battery-backup units</firstterm> (<acronym>BBU</acronym>s), meaning
   the card has a battery that
   maintains power to the cache in case of system power loss.  After power
   is restored the data will be written to the disk drives.
  </para>

  <para>
   And finally, most disk drives have caches. Some are write-through
   while some are write-back, and the same concerns about data loss
   exist for write-back drive caches as for disk controller
   caches.  Consumer-grade IDE and SATA drives are particularly likely
   to have write-back caches that will not survive a power failure.  Many
   solid-state drives (SSD) also have volatile write-back caches.
  </para>

  <para>
   These caches can typically be disabled; however, the method for doing
   this varies by operating system and drive type:
  </para>

  <itemizedlist>
    <listitem>
      <para>
        On <productname>Linux</productname>, IDE and SATA drives can be queried using
        <command>hdparm -I</command>; write caching is enabled if there is
        a <literal>*</literal> next to <literal>Write cache</literal>.  <command>hdparm -W 0</command>
        can be used to turn off write caching.  SCSI drives can be queried
        using <ulink url="http://sg.danny.cz/sg/sdparm.html"><application>sdparm</application></ulink>.
        Use <command>sdparm --get=WCE</command> to check
        whether the write cache is enabled and <command>sdparm --clear=WCE</command>
        to disable it.
      </para>
    </listitem>

    <listitem>
      <para>
        On <productname>FreeBSD</productname>, IDE drives can be queried