files don't normally
       exist on standby servers.
      </para>

      <para>
       If you have tablespaces, you will need to run a similar
       <application>rsync</application> command for each tablespace directory, e.g.:

<programlisting>
rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tblsp/PG_12_201909212 \
      /vol1/pg_tblsp/PG_&majorversion;_202307071 standby.example.com:/vol1/pg_tblsp
</programlisting>

       If you have relocated <filename>pg_wal</filename> outside the data
       directories, <application>rsync</application> must be run on those directories
       too.
      </para>
     </step>

     <step>
      <title>Configure streaming replication and log-shipping standby servers</title>

      <para>
       Configure the servers for log shipping.  (You do not need to run
       <function>pg_backup_start()</function> and <function>pg_backup_stop()</function>
       or take a file system backup as the standbys are still synchronized
       with the primary.) If the old primary is prior to version 17.0, then no
       slots on the primary are copied to the new standby, so all the slots on
       the old standby must be recreated manually. If the old primary is
       version 17.0 or later, then only logical slots on the primary are copied
       to the new standby, but other slots on the old standby are not copied,
       so must be recreated manually.
      </para>
     </step>

    </procedure>

   </step>

   <step>
    <title>Restore <filename>pg_hba.conf</filename></title>

    <para>
     If you modified <filename>pg_hba.conf</filename>, restore its original settings.
     It might also be necessary to adjust other configuration files in the new
     cluster to match the old cluster, e.g., <filename>postgresql.conf</filename>
     (and any files included by it), <filename>postgresql.auto.conf</filename>.
    </para>
   </step>

   <step>
    <title>Start the new server</title>

    <para>
     The new server can now be safely started, and then any
     <application>rsync</application>'ed standby servers.
    </para>
   </step>

   <step>
    <title>Post-upgrade processing</title>

    <para>
     If any post-upgrade processing is required, pg_upgrade will issue
     warnings as it completes. It will also generate script files that must
     be run by the administrator. The script files will connect to each
     database that needs post-upgrade processing. Each script should be
     run using:

<programlisting>
psql --username=postgres --file=script.sql postgres
</programlisting>

     The scripts can be run in any order and can be deleted once they have
     been run.
    </para>

    <caution>
    <para>
     In general it is unsafe to access tables referenced in rebuild scripts
     until the rebuild scripts have run to completion; doing so could yield
     incorrect results or poor performance. Tables not referenced in rebuild
     scripts can be accessed immediately.
    </para>
    </caution>
   </step>

   <step>
    <title>Statistics</title>

    <para>
     Unless the <option>--no-statistics</option> option is specified,
     <command>pg_upgrade</command> will transfer most optimizer statistics
     from the old cluster to the new cluster.  However, some statistics may
     not be transferred, such as those created explicitly with <xref
     linkend="sql-createstatistics"/> or custom statistics added by an
     extension.
    </para>

    <para>
     Because not all statistics are transferred by
     <command>pg_upgrade</command>, you will be instructed to run commands to
     regenerate that information at the end of the upgrade.  You might need to
     set connection parameters to match your new cluster.
    </para>

    <para>
     First, use
     <command>vacuumdb --all --analyze-in-stages --missing-stats-only</command>
     to quickly generate minimal optimizer statistics for relations without
     any.  Then, use <command>vacuumdb --all --analyze-only</command>