groups of the version number,
   e.g., 9.5, and the minor version is the third number, e.g., 3, meaning this
   would be the third minor release of the major release 9.5.
  </para>

  <para>
   Minor releases never change the internal storage format and are always
   compatible with earlier and later minor releases of the same major version
   number.  For example, version 10.1 is compatible with version 10.0 and
   version 10.6.  Similarly, for example, 9.5.3 is compatible with 9.5.0,
   9.5.1, and 9.5.6.  To update between compatible versions, you simply
   replace the executables while the server is down and restart the server.
   The data directory remains unchanged &mdash; minor upgrades are that
   simple.
  </para>

  <para>
   For <emphasis>major</emphasis> releases of <productname>PostgreSQL</productname>, the
   internal data storage format is subject to change, thus complicating
   upgrades.  The traditional method for moving data to a new major version
   is to dump and restore the database, though this can be slow.  A
   faster method is <xref linkend="pgupgrade"/>.  Replication methods are
   also available, as discussed below.
   (If you are using a pre-packaged version
   of <productname>PostgreSQL</productname>, it may provide scripts to
   assist with major version upgrades.  Consult the package-level
   documentation for details.)
  </para>

  <para>
   New major versions also typically introduce some user-visible
   incompatibilities, so application programming changes might be required.
   All user-visible changes are listed in the release notes (<xref
   linkend="release"/>);  pay particular attention to the section
   labeled "Migration".  Though you can upgrade from one major version
   to another without upgrading to intervening versions, you should read
   the major release notes of all intervening versions.
  </para>

  <para>
   Cautious users will want to test their client applications on the new
   version before switching over fully; therefore, it's often a good idea to
   set up concurrent installations of old and new versions.  When
   testing a <productname>PostgreSQL</productname> major upgrade, consider the
   following categories of possible changes:
  </para>

  <variablelist>

   <varlistentry>
    <term>Administration</term>
    <listitem>
     <para>
      The capabilities available for administrators to monitor and control
      the server often change and improve in each major release.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>SQL</term>
    <listitem>
     <para>
      Typically this includes new SQL command capabilities and not changes
      in behavior, unless specifically mentioned in the release notes.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>Library API</term>
    <listitem>
     <para>
      Typically libraries like <application>libpq</application> only add new
      functionality, again unless mentioned in the release notes.
     </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