single query to use multiple servers to
     complete faster.  This solution allows multiple servers to work
     concurrently on a single query.  It is usually accomplished by
     splitting the data among servers and having each server execute its
     part of the query and return results to a central server where they
     are combined and returned to the user. This can be implemented using the
     <productname>PL/Proxy</productname> tool set.
    </para>

   </listitem>
  </varlistentry>

 </variablelist>

  <para>
   It should also be noted that because <productname>PostgreSQL</productname>
   is open source and easily extended, a number of companies have
   taken <productname>PostgreSQL</productname> and created commercial
   closed-source solutions with unique failover, replication, and load
   balancing capabilities.  These are not discussed here.
  </para>

 </sect1>


 <sect1 id="warm-standby">
 <title>Log-Shipping Standby Servers</title>


  <para>
   Continuous archiving can be used to create a <firstterm>high
   availability</firstterm> (HA) cluster configuration with one or more
   <firstterm>standby servers</firstterm> ready to take over operations if the
   primary server fails. This capability is widely referred to as
   <firstterm>warm standby</firstterm> or <firstterm>log shipping</firstterm>.
  </para>

  <para>
   The primary and standby server work together to provide this capability,
   though the servers are only loosely coupled. The primary server operates
   in continuous archiving mode, while each standby server operates in
   continuous recovery mode, reading the WAL files from the primary. No
   changes to the database tables are required to enable this capability,
   so it offers low administration overhead compared to some other
   replication solutions. This configuration also has relatively low
   performance impact on the primary server.
  </para>

  <para>
   Directly moving WAL records from one database server to another
   is typically described as log shipping. <productname>PostgreSQL</productname>
   implements file-based log shipping by transferring WAL records
   one file (WAL segment) at a time. WAL files (16MB) can be
   shipped easily and cheaply over any distance, whether it be to an
   adjacent system, another system at the same site, or another system on
   the far side of the globe. The bandwidth required for this technique
   varies according to the transaction rate of the primary server.
   Record-based log shipping is more granular and streams WAL changes
   incrementally over a network connection (see <xref
   linkend="streaming-replication"/>).
  </para>

  <para>
   It should be noted that log shipping is asynchronous, i.e., the WAL
   records are shipped after transaction commit. As a result, there is a
   window for data loss should the primary server suffer a catastrophic
   failure; transactions not yet shipped will be lost.  The size of the
   data loss window in file-based log shipping can be limited by use of the
   <varname>archive_timeout</varname> parameter, which can be set as low
   as a few seconds.  However such a low setting will
   substantially increase the bandwidth required for file shipping.
   Streaming replication (see <xref linkend="streaming-replication"/>)
   allows a much smaller window of data loss.
  </para>

  <para>
   Recovery performance is sufficiently good that the standby will
   typically be only moments away from full
   availability once it has been activated. As a result, this is called
   a warm standby configuration which offers high
   availability. Restoring a server from an archived base backup and
   rollforward will take considerably longer, so that technique only
   offers a solution for disaster recovery, not high availability.
   A standby server can also be used for read-only queries, in which case
   it is called a <firstterm>hot standby</firstterm> server. See
   <xref linkend="hot-standby"/> for more information.
  </para>