Home Explore Blog CI



postgresql

34th chunk of `doc/src/sgml/high-availability.sgml`
56f82d90e2f0a33c71dc297fcfd92740c25377cc50e032210000000100000883
 (like <structfield>n_tup_ins</structfield>),
    nor will reads or writes performed by the startup process be tracked in the
    <structname>pg_statio_</structname> views, nor will associated
    <structname>pg_stat_database</structname> columns be incremented.
   </para>

   <para>
    Autovacuum is not active during recovery.  It will start normally at the
    end of recovery.
   </para>

   <para>
    The checkpointer process and the background writer process are active during
    recovery. The checkpointer process will perform restartpoints (similar to
    checkpoints on the primary) and the background writer process will perform
    normal block cleaning activities. This can include updates of the hint bit
    information stored on the standby server.
    The <command>CHECKPOINT</command> command is accepted during recovery,
    though it performs a restartpoint rather than a new checkpoint.
   </para>
  </sect2>

  <sect2 id="hot-standby-parameters">
   <title>Hot Standby Parameter Reference</title>

   <para>
    Various parameters have been mentioned above in
    <xref linkend="hot-standby-conflict"/> and
    <xref linkend="hot-standby-admin"/>.
   </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.

Title: Hot Standby Parameters and Caveats
Summary
This section discusses the parameters that can be used in hot standby mode, including those that can be set on the primary and standby servers, and highlights several limitations and caveats of hot standby, such as the requirement for full knowledge of running transactions before snapshots can be taken and the potential delay in starting read-only connections due to long-running write transactions.