(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.