</para>

   <para>
    On the primary, the <xref linkend="guc-wal-level"/> parameter can be used.
    <xref linkend="guc-max-standby-archive-delay"/> and
    <xref linkend="guc-max-standby-streaming-delay"/> have no effect if set on
    the primary.
   </para>

   <para>
    On the standby, parameters <xref linkend="guc-hot-standby"/>,
    <xref linkend="guc-max-standby-archive-delay"/> and
    <xref linkend="guc-max-standby-streaming-delay"/> can be used.
   </para>
  </sect2>

  <sect2 id="hot-standby-caveats">
   <title>Caveats</title>

   <para>
    There are several limitations of hot standby.
    These can and probably will be fixed in future releases:

  <itemizedlist>
   <listitem>
    <para>
     Full knowledge of running transactions is required before snapshots
     can be taken. Transactions that use large numbers of subtransactions
     (currently greater than 64) will delay the start of read-only
     connections until the completion of the longest running write transaction.
     If this situation occurs, explanatory messages will be sent to the server log.
    </para>
   </listitem>
   <listitem>
    <para>
     Valid starting points for standby queries are generated at each
     checkpoint on the primary. If the standby is shut down while the primary
     is in a shutdown state, it might not be possible to re-enter hot standby
     until the primary is started up, so that it generates further starting
     points in the WAL logs.  This situation isn't a problem in the most
     common situations where it might happen. Generally, if the primary is
     shut down and not available anymore, that's likely due to a serious
     failure that requires the standby being converted to operate as
     the new primary anyway.  And in situations where the primary is
     being intentionally taken down, coordinating to make sure the standby
     becomes the new primary smoothly is also standard procedure.
    </para>
   </listitem>
   <listitem>
    <para>
     At the end of recovery, <literal>AccessExclusiveLocks</literal> held by prepared transactions
     will require twice the normal number of lock table entries. If you plan
     on running either a large number of concurrent prepared transactions
     that normally take <literal>AccessExclusiveLocks</literal>, or you plan on having one
     large transaction that takes many <literal>AccessExclusiveLocks</literal>, you are
     advised to select a larger value of <varname>max_locks_per_transaction</varname>,
     perhaps as much as twice the value of the parameter on
     the primary server. You need not consider this at all if
     your setting of <varname>max_prepared_transactions</varname> is 0.
    </para>
   </listitem>
   <listitem>
    <para>
     The Serializable transaction isolation level is not yet available in hot
     standby.  (See <xref linkend="xact-serializable"/> and
     <xref linkend="serializable-consistency"/> for details.)
     An attempt to set a transaction to the serializable isolation level in
     hot standby mode will generate an error.
    </para>
   </listitem>
  </itemizedlist>

   </para>
  </sect2>

 </sect1>

</chapter>