<replaceable>outputfile</replaceable></userinput>
</screen>
      using the <emphasis>new</emphasis> <application>psql</application>.
     </para>
    </step>
   </procedure>

   <para>
    The least downtime can be achieved by installing the new server in
    a different directory and running both the old and the new servers
    in parallel, on different ports. Then you can use something like:

<programlisting>
pg_dumpall -p 5432 | psql -d postgres -p 5433
</programlisting>
    to transfer your data.
   </para>

  </sect2>

  <sect2 id="upgrading-via-pg-upgrade">
   <title>Upgrading Data via <application>pg_upgrade</application></title>

   <para>
    The <xref linkend="pgupgrade"/> module allows an installation to
    be migrated in-place from one major <productname>PostgreSQL</productname>
    version to another.  Upgrades can be performed in minutes,
    particularly with <option>--link</option> mode.  It requires steps similar to
    <application>pg_dumpall</application> above, e.g.,  starting/stopping the server,
    running <application>initdb</application>.  The <application>pg_upgrade</application> <link
    linkend="pgupgrade">documentation</link> outlines the necessary steps.
   </para>

  </sect2>

  <sect2 id="upgrading-via-replication">
   <title>Upgrading Data via Replication</title>

   <para>
    It is also possible to use logical replication methods to create a standby
    server with the updated version of <productname>PostgreSQL</productname>.
    This is possible because logical replication supports
    replication between different major versions of
    <productname>PostgreSQL</productname>.  The standby can be on the same computer or
    a different computer.  Once it has synced up with the primary server
    (running the older version of <productname>PostgreSQL</productname>), you can
    switch primaries and make the standby the primary and shut down the older
    database instance.  Such a switch-over results in only several seconds
    of downtime for an upgrade.
   </para>

   <para>
    This method of upgrading can be performed using the built-in logical
    replication facilities as well as using external logical replication
    systems such as <productname>pglogical</productname>,
    <productname>Slony</productname>, <productname>Londiste</productname>, and
    <productname>Bucardo</productname>.
   </para>
  </sect2>
 </sect1>

 <sect1 id="preventing-server-spoofing">
  <title>Preventing Server Spoofing</title>

  <indexterm zone="preventing-server-spoofing">
   <primary>server spoofing</primary>
  </indexterm>

  <para>
   While the server is running, it is not possible for a malicious user
   to take the place of the normal database server.  However, when the
   server is down, it is possible for a local user to spoof the normal
   server by starting their own server.  The spoof server could read
   passwords and queries sent by clients, but could not return any data
   because the <varname>PGDATA</varname> directory would still be secure because
   of directory permissions. Spoofing is possible because any user can
   start a database server; a client cannot identify an invalid server
   unless it is specially configured.
  </para>

  <para>
   One way to prevent spoofing of <literal>local</literal>
   connections is to use a Unix domain socket directory (<xref
   linkend="guc-unix-socket-directories"/>) that has write permission only
   for a trusted local user.  This prevents a malicious user from creating
   their own socket file in that directory.  If you are concerned that
   some applications might still reference <filename>/tmp</filename> for the
   socket file and hence be vulnerable to spoofing, during operating system
   startup create a symbolic link <filename>/tmp/.s.PGSQL.5432</filename> that points
   to the relocated socket file.  You also might need to modify your
   <filename>/tmp</filename> cleanup script to prevent removal of the symbolic link.
  </para>

  <para>
   Another