<varlistentry>
    <term><envar>PGPORT</envar></term>

    <listitem>
     <para>
      Default port number (preferably set in the configuration file)
     </para>
    </listitem>
   </varlistentry>

  </variablelist>
 </refsect1>

 <refsect1>
   <title>Diagnostics</title>

   <para>
    A failure message mentioning <literal>semget</literal> or
    <literal>shmget</literal> probably indicates you need to configure your
    kernel to provide adequate shared memory and semaphores.  For more
    discussion see <xref linkend="kernel-resources"/>.  You might be able
    to postpone reconfiguring your kernel by decreasing <xref
    linkend="guc-shared-buffers"/> to reduce the shared memory
    consumption of <productname>PostgreSQL</productname>, and/or by reducing
    <xref linkend="guc-max-connections"/> to reduce the semaphore
    consumption.
   </para>

   <para>
    A failure message suggesting that another server is already running
    should be checked carefully, for example by using the command
<screen>
<prompt>$</prompt> <userinput>ps ax | grep postgres</userinput>
</screen>
        or
<screen>
<prompt>$</prompt> <userinput>ps -ef | grep postgres</userinput>
</screen>
    depending on your system.  If you are certain that no conflicting
    server is running, you can remove the lock file mentioned in the
    message and try again.
   </para>

   <para>
    A failure message indicating inability to bind to a port might
    indicate that that port is already in use by some
    non-<productname>PostgreSQL</productname> process.  You might also
    get this error if you terminate <command>postgres</command>
    and immediately restart it using the same port; in this case, you
    must simply wait a few seconds until the operating system closes
    the port before trying again.  Finally, you might get this error if
    you specify a port number that your operating system considers to
    be reserved.  For example, many versions of Unix consider port
    numbers under 1024 to be <quote>trusted</quote> and only permit
    the Unix superuser to access them.
   </para>

 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   The utility command <xref linkend="app-pg-ctl"/> can be used to
   start and shut down the <command>postgres</command> server
   safely and comfortably.
  </para>

  <para>
   If at all possible, <emphasis>do not</emphasis> use
   <literal>SIGKILL</literal> to kill the main
   <command>postgres</command> server.  Doing so will prevent
   <command>postgres</command> from freeing the system
   resources (e.g., shared memory and semaphores) that it holds before
   terminating.  This might cause problems for starting a fresh
   <command>postgres</command> run.
  </para>

  <para>
   To terminate the <command>postgres</command> server normally, the
   signals <literal>SIGTERM</literal>, <literal>SIGINT</literal>, or
   <literal>SIGQUIT</literal> can be used.  The first will wait for
   all clients to terminate before quitting, the second will
   forcefully disconnect all clients, and the third will quit
   immediately without proper shutdown, resulting in a recovery run
   during restart.
  </para>

  <para>
   The <literal>SIGHUP</literal> signal will reload
   the server configuration files.  It is also possible to send
   <literal>SIGHUP</literal> to an individual server process, but that
   is usually not sensible.
  </para>

  <para>
   To cancel a running query, send the <literal>SIGINT</literal> signal
   to the process running that command. To terminate a backend process
   cleanly, send <literal>SIGTERM</literal> to that process. See
   also <function>pg_cancel_backend</function> and <function>pg_terminate_backend</function>
   in <xref linkend="functions-admin-signal"/> for the SQL-callable equivalents
   of these two actions.
  </para>

  <para>
   The <command>postgres</command> server uses <literal>SIGQUIT</literal>
   to tell subordinate server processes to terminate without normal
   cleanup.