to enable mode-specific checks.
     <command>pg_upgrade</command> requires write permission in the current directory.
    </para>

    <para>
     Obviously, no one should be accessing the clusters during the
     upgrade.  <application>pg_upgrade</application> defaults to running servers
     on port 50432 to avoid unintended client connections.
     You can use the same port number for both clusters when doing an
     upgrade because the old and new clusters will not be running at the
     same time.  However, when checking an old running server, the old
     and new port numbers must be different.
    </para>

    <para>
     If an error occurs while restoring the database schema, <command>pg_upgrade</command> will
     exit and you will have to revert to the old cluster as outlined in <xref linkend="pgupgrade-step-revert"/>
     below. To try <command>pg_upgrade</command> again, you will need to modify the old
     cluster so the pg_upgrade schema restore succeeds. If the problem is a
     <filename>contrib</filename> module, you might need to uninstall the <filename>contrib</filename> module from
     the old cluster and install it in the new cluster after the upgrade,
     assuming the module is not being used to store user data.
    </para>
   </step>

   <step id="pgupgrade-step-replicas">
    <title>Upgrade streaming replication and log-shipping standby servers</title>

    <para>
     If you used link mode and have Streaming Replication (see <xref
     linkend="streaming-replication"/>) or Log-Shipping (see <xref
     linkend="warm-standby"/>) standby servers, you can follow these steps to
     quickly upgrade them.  You will not be running <application>pg_upgrade</application> on
     the standby servers, but rather <application>rsync</application> on the primary.
     Do not start any servers yet.
    </para>

    <para>
     If you did <emphasis>not</emphasis> use link mode, do not have or do not
     want to use <application>rsync</application>, or want an easier solution, skip
     the instructions in this section and simply recreate the standby
     servers once <application>pg_upgrade</application> completes and the new primary
     is running.
    </para>

    <procedure>

     <step>
      <title>Install the new PostgreSQL binaries on standby servers</title>

      <para>
       Make sure the new binaries and support files are installed on all
       standby servers.
      </para>
     </step>

     <step>
      <title>Make sure the new standby data directories do <emphasis>not</emphasis> exist</title>

      <para>
       Make sure the new standby data directories do <emphasis>not</emphasis>
       exist or are empty.  If <application>initdb</application> was run, delete
       the standby servers' new data directories.
      </para>
     </step>

     <step>
      <title>Install extension shared object files</title>

      <para>
       Install the same extension shared object files on the new standbys
       that you installed in the new primary cluster.
      </para>
     </step>

     <step>
      <title>Stop standby servers</title>

      <para>
       If the standby servers are still running, stop them now using the
       above instructions.
      </para>
     </step>

     <step>
      <title>Save configuration files</title>

      <para>
       Save any configuration files from the old standbys' configuration
       directories you need to keep, e.g.,  <filename>postgresql.conf</filename>
       (and any files included by it), <filename>postgresql.auto.conf</filename>,
       <literal>pg_hba.conf</literal>, because these will be overwritten
       or removed in the next step.
      </para>
     </step>

     <step>
      <title>Run <application>rsync</application></title>

      <para>
       When using link mode, standby servers can be quickly upgraded using
       <application>rsync</application>.  To accomplish this, from a directory on
       the primary server that is above the old and new database