<application>pg_upgrade</application> completes
   successfully; but in the event of trouble, the files there may provide
   useful debugging information.
  </para>

  <para>
   <application>pg_upgrade</application> launches short-lived postmasters in
   the old and new data directories.  Temporary Unix socket files for
   communication with these postmasters are, by default, made in the current
   working directory.  In some situations the path name for the current
   directory might be too long to be a valid socket name.  In that case you
   can use the <option>-s</option> option to put the socket files in some
   directory with a shorter path name.  For security, be sure that that
   directory is not readable or writable by any other users.
   (This is not supported on Windows.)
  </para>

  <para>
   All failure, rebuild, and reindex cases will be reported by
   <application>pg_upgrade</application> if they affect your installation;
   post-upgrade scripts to rebuild tables and indexes will be
   generated automatically.  If you are trying to automate the upgrade
   of many clusters, you should find that clusters with identical database
   schemas require the same post-upgrade steps for all cluster upgrades;
   this is because the post-upgrade steps are based on the database
   schemas, and not user data.
  </para>

  <para>
   For deployment testing, create a schema-only copy of the old cluster,
   insert dummy data, and upgrade that.
  </para>

  <para>
   <application>pg_upgrade</application> does not support upgrading of databases
   containing table columns using these <type>reg*</type> OID-referencing system data types:
   <simplelist>
    <member><type>regcollation</type></member>
    <member><type>regconfig</type></member>
    <member><type>regdictionary</type></member>
    <member><type>regnamespace</type></member>
    <member><type>regoper</type></member>
    <member><type>regoperator</type></member>
    <member><type>regproc</type></member>
    <member><type>regprocedure</type></member>
   </simplelist>
   (<type>regclass</type>, <type>regrole</type>, and <type>regtype</type> can be upgraded.)
  </para>

  <para>
   If you want to use link mode and you do not want your old cluster
   to be modified when the new cluster is started, consider using the clone mode.
   If that is not available, make a copy of the
   old cluster and upgrade that in link mode. To make a valid copy
   of the old cluster, use <command>rsync</command> to create a dirty
   copy of the old cluster while the server is running, then shut down
   the old server and run <command>rsync --checksum</command> again to update the
   copy with any changes to make it consistent.  (<option>--checksum</option>
   is necessary because <command>rsync</command> only has file modification-time
   granularity of one second.)  You might want to exclude some
   files, e.g., <filename>postmaster.pid</filename>, as documented in <xref
   linkend="backup-lowlevel-base-backup"/>.  If your file system supports
   file system snapshots or copy-on-write file copies, you can use that
   to make a backup of the old cluster and tablespaces, though the snapshot
   and copies must be created simultaneously or while the database server
   is down.
  </para>

 </refsect1>

 <refsect1>
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="app-initdb"/></member>
   <member><xref linkend="app-pg-ctl"/></member>
   <member><xref linkend="app-pgdump"/></member>
   <member><xref linkend="app-postgres"/></member>
  </simplelist>
 </refsect1>
</refentry>