</listitem>
       <listitem>
        <para>
         Interfacing with other backup and recovery software
        </para>
       </listitem>
       <listitem>
        <para>
         Interfacing with monitoring software to report errors
        </para>
       </listitem>
      </itemizedlist>
     </para>

     <tip>
      <para>
       When using an <varname>archive_command</varname> script, it's desirable
       to enable <xref linkend="guc-logging-collector"/>.
       Any messages written to <systemitem>stderr</systemitem> from the script will then
       appear in the database server log, allowing complex configurations to
       be diagnosed easily if they fail.
      </para>
     </tip>
    </sect3>
  </sect2>

  <sect2 id="continuous-archiving-caveats">
   <title>Caveats</title>

   <para>
    At this writing, there are several limitations of the continuous archiving
    technique.  These will probably be fixed in future releases:

  <itemizedlist>
   <listitem>
    <para>
     If a <link linkend="sql-createdatabase"><command>CREATE DATABASE</command></link>
     command is executed while a base backup is being taken, and then
     the template database that the <command>CREATE DATABASE</command> copied
     is modified while the base backup is still in progress, it is
     possible that recovery will cause those modifications to be
     propagated into the created database as well.  This is of course
     undesirable.  To avoid this risk, it is best not to modify any
     template databases while taking a base backup.
    </para>
   </listitem>

   <listitem>
    <para>
     <link linkend="sql-createtablespace"><command>CREATE TABLESPACE</command></link>
     commands are WAL-logged with the literal absolute path, and will
     therefore be replayed as tablespace creations with the same
     absolute path.  This might be undesirable if the WAL is being
     replayed on a different machine.  It can be dangerous even if the
     WAL is being replayed on the same machine, but into a new data
     directory: the replay will still overwrite the contents of the
     original tablespace.  To avoid potential gotchas of this sort,
     the best practice is to take a new base backup after creating or
     dropping tablespaces.
    </para>
   </listitem>
  </itemizedlist>
   </para>

   <para>
    It should also be noted that the default <acronym>WAL</acronym>
    format is fairly bulky since it includes many disk page snapshots.
    These page snapshots are designed to support crash recovery, since
    we might need to fix partially-written disk pages.  Depending on
    your system hardware and software, the risk of partial writes might
    be small enough to ignore, in which case you can significantly
    reduce the total volume of archived WAL files by turning off page
    snapshots using the <xref linkend="guc-full-page-writes"/>
    parameter.  (Read the notes and warnings in <xref linkend="wal"/>
    before you do so.)  Turning off page snapshots does not prevent
    use of the WAL for PITR operations.  An area for future
    development is to compress archived WAL data by removing
    unnecessary page copies even when <varname>full_page_writes</varname> is
    on.  In the meantime, administrators might wish to reduce the number
    of page snapshots included in WAL by increasing the checkpoint
    interval parameters as much as feasible.
   </para>
  </sect2>
 </sect1>

</chapter>