</para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>System Catalogs</term>
    <listitem>
     <para>
      System catalog changes usually only affect database management tools.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>Server C-language API</term>
    <listitem>
     <para>
      This involves changes in the backend function API, which is written
      in the C programming language.  Such changes affect code that
      references backend functions deep inside the server.
     </para>
    </listitem>
   </varlistentry>

  </variablelist>

  <sect2 id="upgrading-via-pgdumpall">
   <title>Upgrading Data via <application>pg_dumpall</application></title>

   <para>
    One upgrade method is to dump data from one major version of
    <productname>PostgreSQL</productname> and restore it in another &mdash;  to do
    this, you must use a <emphasis>logical</emphasis> backup tool like
    <application>pg_dumpall</application>; file system
    level backup methods will not work. (There are checks in place that prevent
    you from using a data directory with an incompatible version of
    <productname>PostgreSQL</productname>, so no great harm can be done by
    trying to start the wrong server version on a data directory.)
   </para>

   <para>
    It is recommended that you use the <application>pg_dump</application> and
    <application>pg_dumpall</application> programs from the <emphasis>newer</emphasis>
    version of
    <productname>PostgreSQL</productname>, to take advantage of enhancements
    that might have been made in these programs.  Current releases of the
    dump programs can read data from any server version back to 9.2.
   </para>

   <para>
    These instructions assume that your existing installation is under the
    <filename>/usr/local/pgsql</filename> directory, and that the data area is in
    <filename>/usr/local/pgsql/data</filename>.  Substitute your paths
    appropriately.
   </para>

   <procedure>
    <step>
     <para>
      If making a backup, make sure that your database is not being updated.
      This does not affect the integrity of the backup, but the changed
      data would of course not be included. If necessary, edit the
      permissions in the file <filename>/usr/local/pgsql/data/pg_hba.conf</filename>
      (or equivalent) to disallow access from everyone except you.
      See <xref linkend="client-authentication"/> for additional information on
      access control.
     </para>

     <para>
      <indexterm>
       <primary>pg_dumpall</primary>
       <secondary>use during upgrade</secondary>
      </indexterm>

      To back up your database installation, type:
<screen>
<userinput>pg_dumpall &gt; <replaceable>outputfile</replaceable></userinput>
</screen>
     </para>

     <para>
      To make the backup, you can use the <application>pg_dumpall</application>
      command from the version you are currently running;  see <xref
      linkend="backup-dump-all"/> for more details.  For best
      results, however, try to use the <application>pg_dumpall</application>
      command from <productname>PostgreSQL</productname> &version;,
      since this version contains bug fixes and improvements over older
      versions.  While this advice might seem idiosyncratic since you
      haven't installed the new version yet, it is advisable to follow
      it if you plan to install the new version in parallel with the
      old version.  In that case you can complete the installation
      normally and transfer the data later.  This will also decrease
      the downtime.
     </para>
    </step>

    <step>
     <para>
      Shut down the old server:
<screen>
<userinput>pg_ctl stop</userinput>
</screen>
      On systems that have <productname>PostgreSQL</productname> started at boot time,
      there is probably a start-up file that will accomplish the same thing. For
      example, on a <systemitem class="osname">Red Hat Linux</systemitem> system