connect and disconnect frequently, you
    might want to make adjustments to handle the period when
    <varname>hot_standby_feedback</varname> feedback is not being provided.
    For example, consider increasing <varname>max_standby_archive_delay</varname>
    so that queries are not rapidly canceled by conflicts in WAL archive
    files during disconnected periods.  You should also consider increasing
    <varname>max_standby_streaming_delay</varname> to avoid rapid cancellations
    by newly-arrived streaming WAL entries after reconnection.
   </para>

   <para>
    The number of query cancels and the reason for them can be viewed using
    the <structname>pg_stat_database_conflicts</structname> system view on the standby
    server. The <structname>pg_stat_database</structname> system view also contains
    summary information.
   </para>

   <para>
    Users can control whether a log message is produced when WAL replay is waiting
    longer than <varname>deadlock_timeout</varname> for conflicts. This
    is controlled by the <xref linkend="guc-log-recovery-conflict-waits"/> parameter.
   </para>
  </sect2>

  <sect2 id="hot-standby-admin">
   <title>Administrator's Overview</title>

   <para>
    If <varname>hot_standby</varname> is <literal>on</literal> in <filename>postgresql.conf</filename>
    (the default value) and there is a
    <link linkend="file-standby-signal"><filename>standby.signal</filename></link><indexterm><primary>standby.signal</primary><secondary>for hot standby</secondary></indexterm>
    file present, the server will run in hot standby mode.
    However, it may take some time for hot standby connections to be allowed,
    because the server will not accept connections until it has completed
    sufficient recovery to provide a consistent state against which queries
    can run.  During this period,
    clients that attempt to connect will be refused with an error message.
    To confirm the server has come up, either loop trying to connect from
    the application, or look for these messages in the server logs:

<programlisting>
LOG:  entering standby mode

... then some time later ...

LOG:  consistent recovery state reached
LOG:  database system is ready to accept read-only connections
</programlisting>

    Consistency information is recorded once per checkpoint on the primary.
    It is not possible to enable hot standby when reading WAL
    written during a period when <varname>wal_level</varname> was not set to
    <literal>replica</literal> or <literal>logical</literal> on the primary.
    Even after reaching a consistent state, the recovery snapshot may not
    be ready for hot standby if both of the following conditions are met,
    delaying accepting read-only connections.  To enable hot standby,
    long-lived write transactions with more than 64 subtransactions
    need to be closed on the primary.

      <itemizedlist>
       <listitem>
        <para>
         A write transaction has more than 64 subtransactions
        </para>
       </listitem>
       <listitem>
        <para>
         Very long-lived write transactions
        </para>
       </listitem>
      </itemizedlist>

    If you are running file-based log shipping ("warm standby"), you might need
    to wait until the next WAL file arrives, which could be as long as the
    <varname>archive_timeout</varname> setting on the primary.
   </para>

   <para>
    The settings of some parameters determine the size of shared memory for
    tracking transaction IDs, locks, and prepared transactions.  These shared
    memory structures must be no smaller on a standby than on the primary in
    order to ensure that the standby does not run out of shared memory during
    recovery.  For example, if the primary had used a prepared transaction but
    the standby had not allocated any shared memory for tracking prepared
    transactions, then recovery could not continue until the standby's
    configuration is changed.  The parameters affected