triggers.
   </para>

   <para>
    New OIDs cannot be assigned, though some <acronym>UUID</acronym> generators may still
    work as long as they do not rely on writing new status to the database.
   </para>

   <para>
    Currently, temporary table creation is not allowed during read-only
    transactions, so in some cases existing scripts will not run correctly.
    This restriction might be relaxed in a later release. This is
    both an SQL standard compliance issue and a technical issue.
   </para>

   <para>
    <command>DROP TABLESPACE</command> can only succeed if the tablespace is empty.
    Some standby users may be actively using the tablespace via their
    <varname>temp_tablespaces</varname> parameter. If there are temporary files in the
    tablespace, all active queries are canceled to ensure that temporary
    files are removed, so the tablespace can be removed and WAL replay
    can continue.
   </para>

   <para>
    Running <command>DROP DATABASE</command> or <command>ALTER DATABASE ... SET
    TABLESPACE</command> on the primary
    will generate a WAL entry that will cause all users connected to that
    database on the standby to be forcibly disconnected. This action occurs
    immediately, whatever the setting of
    <varname>max_standby_streaming_delay</varname>. Note that
    <command>ALTER DATABASE ... RENAME</command> does not disconnect users, which
    in most cases will go unnoticed, though might in some cases cause a
    program confusion if it depends in some way upon database name.
   </para>

   <para>
    In normal (non-recovery) mode, if you issue <command>DROP USER</command> or <command>DROP ROLE</command>
    for a role with login capability while that user is still connected then
    nothing happens to the connected user &mdash; they remain connected. The user cannot
    reconnect however. This behavior applies in recovery also, so a
    <command>DROP USER</command> on the primary does not disconnect that user on the standby.
   </para>

   <para>
    The cumulative statistics system is active during recovery. All scans,
    reads, blocks, index usage, etc., will be recorded normally on the
    standby. However, WAL replay will not increment relation and database
    specific counters. I.e. replay will not increment
    <structname>pg_stat_all_tables</structname> columns (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