and you are advised to keep primary
    and standby servers at the same release level as much as possible.
    When updating to a new minor release, the safest policy is to update
    the standby servers first — a new minor release is more likely
    to be able to read WAL files from a previous minor release than vice
    versa.
   </para>

  </sect2>

  <sect2 id="standby-server-operation" xreflabel="Standby Server Operation">
   <title>Standby Server Operation</title>

   <para>
    A server enters standby mode if a
    <anchor id="file-standby-signal" xreflabel="standby.signal"/>
    <filename>standby.signal</filename>
    <indexterm><primary><filename>standby.signal</filename></primary></indexterm>
    file exists in the data directory when the server is started.
   </para>

   <para>
    In standby mode, the server continuously applies WAL received from the
    primary server. The standby server can read WAL from a WAL archive
    (see <xref linkend="guc-restore-command"/>) or directly from the primary
    over a TCP connection (streaming replication). The standby server will
    also attempt to restore any WAL found in the standby cluster's
    <filename>pg_wal</filename> directory. That typically happens after a server
    restart, when the standby replays again WAL that was streamed from the
    primary before the restart, but you can also manually copy files to
    <filename>pg_wal</filename> at any time to have them replayed.
   </para>

   <para>
    At startup, the standby begins by restoring all WAL available in the
    archive location, calling <varname>restore_command</varname>. Once it
    reaches the end of WAL available there and <varname>restore_command</varname>
    fails, it tries to restore any WAL available in the <filename>pg_wal</filename> directory.
    If that fails, and streaming replication has been configured, the
    standby tries to connect to the primary server and start streaming WAL
    from the last valid record found in archive or <filename>pg_wal</filename>. If that fails
    or streaming replication is not configured, or if the connection is
    later disconnected, the standby goes back to step 1 and tries to
    restore the file from the archive again. This loop of retries from the
    archive, <filename>pg_wal</filename>, and via streaming replication goes on until the server
    is stopped or is promoted.
   </para>

   <para>
    Standby mode is exited and the server switches to normal operation
    when <command>pg_ctl promote</command> is run, or
    <function>pg_promote()</function> is called. Before failover,
    any WAL immediately available in the archive or in <filename>pg_wal</filename>
    will be restored, but no attempt is made to connect to the primary.
   </para>
  </sect2>

  <sect2 id="preparing-primary-for-standby">
   <title>Preparing the Primary for Standby Servers</title>

   <para>
    Set up continuous archiving on the primary to an archive directory
    accessible from the standby, as described
    in <xref linkend="continuous-archiving"/>. The archive location should be
    accessible from the standby even when the primary is down, i.e., it should
    reside on the standby server itself or another trusted server, not on
    the primary server.
   </para>

   <para>
    If you want to use streaming replication, set up authentication on the
    primary server to allow replication connections from the standby
    server(s); that is, create a role and provide a suitable entry or
    entries in <filename>pg_hba.conf</filename> with the database field set to
    <literal>replication</literal>.  Also ensure <varname>max_wal_senders</varname> is set
    to a sufficiently large value in the configuration file of the primary
    server. If replication slots will be used,
    ensure that <varname>max_replication_slots</varname> is set sufficiently
    high as well.
   </para>

   <para>
    Take a base backup as described in <xref linkend="backup-base-backup"/>
    to