<firstterm>Immediate Shutdown</firstterm> mode.
      The server will send <systemitem>SIGQUIT</systemitem> to all child
      processes and wait for them to terminate.  If any do not terminate
      within 5 seconds, they will be sent <systemitem>SIGKILL</systemitem>.
      The supervisor server process exits as soon as all child processes have
      exited, without doing normal database shutdown processing.
      This will lead to recovery (by
      replaying the WAL log) upon next start-up. This is recommended
      only in emergencies.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   The <xref linkend="app-pg-ctl"/> program provides a convenient
   interface for sending these signals to shut down the server.
   Alternatively, you can send the signal directly using <command>kill</command>
   on non-Windows systems.
   The <acronym>PID</acronym> of the <command>postgres</command> process can be
   found using the <command>ps</command> program, or from the file
   <filename>postmaster.pid</filename> in the data directory. For
   example, to do a fast shutdown:
<screen>
$ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput>
</screen>
  </para>

  <important>
   <para>
    It is best not to use <systemitem>SIGKILL</systemitem> to shut down the
    server.  Doing so will prevent the server from releasing shared memory and
    semaphores.  Furthermore, <systemitem>SIGKILL</systemitem> kills
    the <command>postgres</command> process without letting it relay the
    signal to its subprocesses, so it might be necessary to kill the
    individual subprocesses by hand as well.
   </para>
  </important>

  <para>
   To terminate an individual session while allowing other sessions to
   continue, use <function>pg_terminate_backend()</function> (see <xref
   linkend="functions-admin-signal-table"/>) or send a
   <systemitem>SIGTERM</systemitem> signal to the child process associated with
   the session.
  </para>
 </sect1>

 <sect1 id="upgrading">
  <title>Upgrading a <productname>PostgreSQL</productname> Cluster</title>

  <indexterm zone="upgrading">
   <primary>upgrading</primary>
  </indexterm>

  <indexterm zone="upgrading">
   <primary>version</primary>
   <secondary>compatibility</secondary>
  </indexterm>

  <para>
   This section discusses how to upgrade your database data from one
   <productname>PostgreSQL</productname> release to a newer one.
  </para>

  <para>
   Current <productname>PostgreSQL</productname> version numbers consist of a
   major and a minor version number.  For example, in the version number 10.1,
   the 10 is the major version number and the 1 is the minor version number,
   meaning this would be the first minor release of the major release 10.  For
   releases before <productname>PostgreSQL</productname> version 10.0, version
   numbers consist of three numbers, for example, 9.5.3.  In those cases, the
   major version consists of the first two digit 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