the above when TCP/IP
     communication is attempted. A common mistake is to forget to
     configure <xref linkend="guc-listen-addresses"/> so that the server
     accepts remote TCP connections.
    </para>

    <para>
     Alternatively, you might get this when attempting Unix-domain socket
     communication to a local server:
<screen>
psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory
        Is the server running locally and accepting connections on that socket?
</screen>
     If the server is indeed running, check that the client's idea of the
     socket path (here <literal>/tmp</literal>) agrees with the server's
     <xref linkend="guc-unix-socket-directories"/> setting.
    </para>

    <para>
     A connection failure message always shows the server address or socket
     path name, which is useful in verifying that the client is trying to
     connect to the right place. If there is in fact no server
     listening there, the kernel error message will typically be either
     <computeroutput>Connection refused</computeroutput> or
     <computeroutput>No such file or directory</computeroutput>, as
     illustrated. (It is important to realize that
     <computeroutput>Connection refused</computeroutput> in this context
     does <emphasis>not</emphasis> mean that the server got your
     connection request and rejected it. That case will produce a
     different message, as shown in <xref
     linkend="client-authentication-problems"/>.) Other error messages
     such as <computeroutput>Connection timed out</computeroutput> might
     indicate more fundamental problems, like lack of network
     connectivity, or a firewall blocking the connection.
    </para>
   </sect2>
  </sect1>

 <sect1 id="kernel-resources">
  <title>Managing Kernel Resources</title>

  <para>
   <productname>PostgreSQL</productname> can sometimes exhaust various operating system
   resource limits, especially when multiple copies of the server are running
   on the same system, or in very large installations.  This section explains
   the kernel resources used by <productname>PostgreSQL</productname> and the steps you
   can take to resolve problems related to kernel resource consumption.
  </para>

  <sect2 id="sysvipc">
   <title>Shared Memory and Semaphores</title>

   <indexterm zone="sysvipc">
    <primary>shared memory</primary>
   </indexterm>

   <indexterm zone="sysvipc">
    <primary>semaphores</primary>
   </indexterm>

   <para>
    <productname>PostgreSQL</productname> requires the operating system to provide
    inter-process communication (<acronym>IPC</acronym>) features, specifically
    shared memory and semaphores.  Unix-derived systems typically provide
    <quote><systemitem class="osname">System V</systemitem></quote> <acronym>IPC</acronym>,
    <quote><systemitem class="osname">POSIX</systemitem></quote> <acronym>IPC</acronym>, or both.
    <systemitem class="osname">Windows</systemitem> has its own implementation of
    these features and is not discussed here.
   </para>

   <para>
    By default, <productname>PostgreSQL</productname> allocates
    a very small amount of System V shared memory, as well as a much larger
    amount of anonymous <function>mmap</function> shared memory.
    Alternatively, a single large System V shared memory region can be used
    (see <xref linkend="guc-shared-memory-type"/>).

    In addition a significant number of semaphores, which can be either
    System V or POSIX style, are created at server startup.  Currently,
    POSIX semaphores are used on Linux and FreeBSD systems while other
    platforms use System V semaphores.
   </para>

   <para>
    System V <acronym>IPC</acronym> features are typically constrained by
    system-wide allocation limits.
    When <productname>PostgreSQL</productname> exceeds one of these limits,
    the server will refuse to start and
    should leave an instructive error message describing the problem