can then restart the server after making the necessary configuration changes.
</screen>
    At that point, the settings on the standby need to be updated and the
    instance restarted before recovery can continue.  If the standby is not a
    hot standby, then when it encounters the incompatible parameter change, it
    will shut down immediately without pausing, since there is then no value
    in keeping it up.
   </para>

   <para>
    It is important that the administrator select appropriate settings for
    <xref linkend="guc-max-standby-archive-delay"/> and <xref
    linkend="guc-max-standby-streaming-delay"/>.  The best choices vary
    depending on business priorities.  For example if the server is primarily
    tasked as a High Availability server, then you will want low delay
    settings, perhaps even zero, though that is a very aggressive setting. If
    the standby server is tasked as an additional server for decision support
    queries then it might be acceptable to set the maximum delay values to
    many hours, or even -1 which means wait forever for queries to complete.
   </para>

   <para>
    Transaction status "hint bits" written on the primary are not WAL-logged,
    so data on the standby will likely re-write the hints again on the standby.
    Thus, the standby server will still perform disk writes even though
    all users are read-only; no changes occur to the data values
    themselves.  Users will still write large sort temporary files and
    re-generate relcache info files, so no part of the database
    is truly read-only during hot standby mode.
    Note also that writes to remote databases using
    <application>dblink</application> module, and other operations outside the
    database using PL functions will still be possible, even though the
    transaction is read-only locally.
   </para>

   <para>
    The following types of administration commands are not accepted
    during recovery mode:

      <itemizedlist>
       <listitem>
        <para>
         Data Definition Language (DDL): e.g., <command>CREATE INDEX</command>
        </para>
       </listitem>
       <listitem>
        <para>
         Privilege and Ownership: <command>GRANT</command>, <command>REVOKE</command>,
         <command>REASSIGN</command>
        </para>
       </listitem>
       <listitem>
        <para>
         Maintenance commands: <command>ANALYZE</command>, <command>VACUUM</command>,
         <command>CLUSTER</command>, <command>REINDEX</command>
        </para>
       </listitem>
      </itemizedlist>
   </para>

   <para>
    Again, note that some of these commands are actually allowed during
    "read only" mode transactions on the primary.
   </para>

   <para>
    As a result, you cannot create additional indexes that exist solely
    on the standby, nor statistics that exist solely on the standby.
    If these administration commands are needed, they should be executed
    on the primary, and eventually those changes will propagate to the
    standby.
   </para>

   <para>
    <function>pg_cancel_backend()</function>
    and <function>pg_terminate_backend()</function> will work on user backends,
    but not the startup process, which performs
    recovery. <structname>pg_stat_activity</structname> does not show
    recovering transactions as active. As a result,
    <structname>pg_prepared_xacts</structname> is always empty during
    recovery. If you wish to resolve in-doubt prepared transactions, view
    <literal>pg_prepared_xacts</literal> on the primary and issue commands to
    resolve transactions there or resolve them after the end of recovery.
   </para>

   <para>
    <structname>pg_locks</structname> will show locks held by backends,
    as normal. <structname>pg_locks</structname> also shows
    a virtual transaction managed by the startup process that owns all
    <literal>AccessExclusiveLocks</literal> held by transactions being replayed by recovery.
    Note that the startup process does not