</para>
  </sect2>

  <sect2 id="hot-standby-conflict">
   <title>Handling Query Conflicts</title>

   <para>
    The primary and standby servers are in many ways loosely connected. Actions
    on the primary will have an effect on the standby. As a result, there is
    potential for negative interactions or conflicts between them. The easiest
    conflict to understand is performance: if a huge data load is taking place
    on the primary then this will generate a similar stream of WAL records on the
    standby, so standby queries may contend for system resources, such as I/O.
   </para>

   <para>
    There are also additional types of conflict that can occur with hot standby.
    These conflicts are <emphasis>hard conflicts</emphasis> in the sense that queries
    might need to be canceled and, in some cases, sessions disconnected to resolve them.
    The user is provided with several ways to handle these
    conflicts. Conflict cases include:

      <itemizedlist>
       <listitem>
        <para>
         Access Exclusive locks taken on the primary server, including both
         explicit <command>LOCK</command> commands and various <acronym>DDL</acronym>
         actions, conflict with table accesses in standby queries.
        </para>
       </listitem>
       <listitem>
        <para>
         Dropping a tablespace on the primary conflicts with standby queries
         using that tablespace for temporary work files.
        </para>
       </listitem>
       <listitem>
        <para>
         Dropping a database on the primary conflicts with sessions connected
         to that database on the standby.
        </para>
       </listitem>
       <listitem>
        <para>
         Application of a vacuum cleanup record from WAL conflicts with
         standby transactions whose snapshots can still <quote>see</quote> any of
         the rows to be removed.
        </para>
       </listitem>
       <listitem>
        <para>
         Application of a vacuum cleanup record from WAL conflicts with
         queries accessing the target page on the standby, whether or not
         the data to be removed is visible.
        </para>
       </listitem>
      </itemizedlist>
   </para>

   <para>
    On the primary server, these cases simply result in waiting; and the
    user might choose to cancel either of the conflicting actions.  However,
    on the standby there is no choice: the WAL-logged action already occurred
    on the primary so the standby must not fail to apply it.  Furthermore,
    allowing WAL application to wait indefinitely may be very undesirable,
    because the standby's state will become increasingly far behind the
    primary's.  Therefore, a mechanism is provided to forcibly cancel standby
    queries that conflict with to-be-applied WAL records.
   </para>

   <para>
    An example of the problem situation is an administrator on the primary
    server running <command>DROP TABLE</command> on a table that is currently being
    queried on the standby server.  Clearly the standby query cannot continue
    if the <command>DROP TABLE</command> is applied on the standby. If this situation
    occurred on the primary, the <command>DROP TABLE</command> would wait until the
    other query had finished. But when <command>DROP TABLE</command> is run on the
    primary, the primary doesn't have information about what queries are
    running on the standby, so it will not wait for any such standby
    queries. The WAL change records come through to the standby while the
    standby query is still running, causing a conflict.  The standby server
    must either delay application of the WAL records (and everything after
    them, too) or else cancel the conflicting query so that the <command>DROP
    TABLE</command> can be applied.
   </para>

   <para>
    When a conflicting query is short, it's typically desirable to allow it to
    complete by delaying WAL application for a little bit; but a long delay in
    WAL application