<listitem>

    <para>
     Warm and hot standby servers can be kept current by reading a
     stream of write-ahead log (<acronym>WAL</acronym>)
     records.  If the main server fails, the standby contains
     almost all of the data of the main server, and can be quickly
     made the new primary database server.  This can be synchronous or
     asynchronous and can only be done for the entire database server.
    </para>
    <para>
     A standby server can be implemented using file-based log shipping
     (<xref linkend="warm-standby"/>) or streaming replication (see
     <xref linkend="streaming-replication"/>), or a combination of both. For
     information on hot standby, see <xref linkend="hot-standby"/>.
    </para>
   </listitem>
  </varlistentry>

  <varlistentry>
   <term>Logical Replication</term>
   <listitem>
    <para>
     Logical replication allows a database server to send a stream of data
     modifications to another server.  <productname>PostgreSQL</productname>
     logical replication constructs a stream of logical data modifications
     from the WAL.  Logical replication allows replication of data changes on
     a per-table basis.  In addition, a server that is publishing its own
     changes can also subscribe to changes from another server, allowing data
     to flow in multiple directions.  For more information on logical
     replication, see <xref linkend="logical-replication"/>.  Through the
     logical decoding interface (<xref linkend="logicaldecoding"/>),
     third-party extensions can also provide similar functionality.
    </para>
   </listitem>
  </varlistentry>

  <varlistentry>
   <term>Trigger-Based Primary-Standby Replication</term>
   <listitem>

    <para>
     A trigger-based replication setup typically funnels data modification
     queries to a designated primary server. Operating on a per-table basis,
     the primary server sends data changes (typically) asynchronously to the
     standby servers.  Standby servers can answer queries while the primary is
     running, and may allow some local data changes or write activity.  This
     form of replication is often used for offloading large analytical or data
     warehouse queries.
    </para>

    <para>
     <productname>Slony-I</productname> is an example of this type of
     replication, with per-table granularity, and support for multiple standby
     servers.  Because it updates the standby server asynchronously (in
     batches), there is possible data loss during fail over.
    </para>
   </listitem>
  </varlistentry>

  <varlistentry>
   <term>SQL-Based Replication Middleware</term>
   <listitem>

    <para>
     With SQL-based replication middleware, a program intercepts
     every SQL query and sends it to one or all servers.  Each server
     operates independently.  Read-write queries must be sent to all servers,
     so that every server receives any changes.  But read-only queries can be
     sent to just one server, allowing the read workload to be distributed
     among them.
    </para>

    <para>
     If queries are simply broadcast unmodified, functions like
     <function>random()</function>, <function>CURRENT_TIMESTAMP</function>, and
     sequences can have different values on different servers.
     This is because each server operates independently, and because
     SQL queries are broadcast rather than actual data changes.  If
     this is unacceptable, either the middleware or the application
     must determine such values from a single source and then use those
     values in write queries.  Care must also be taken that all
     transactions either commit or abort on all servers, perhaps
     using two-phase commit (<xref linkend="sql-prepare-transaction"/>
     and <xref linkend="sql-commit-prepared"/>).
     <productname>Pgpool-II</productname> and <productname>Continuent Tungsten</productname>
     are examples of this type of replication.
    </para>
   </listitem>
  </varlistentry>

  <varlistentry>