use</computeroutput> or some variant of that, there might
     be a different problem. For example, trying to start a server
     on a reserved port number might draw something like:
<screen>
$ <userinput>postgres -p 666</userinput>
LOG:  could not bind IPv4 address "127.0.0.1": Permission denied
HINT:  Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL:  could not create any TCP/IP sockets
</screen>
    </para>

    <para>
     A message like:
<screen>
FATAL:  could not create shared memory segment: Invalid argument
DETAIL:  Failed system call was shmget(key=5440001, size=4011376640, 03600).
</screen>
     probably means your kernel's limit on the size of shared memory is
     smaller than the work area <productname>PostgreSQL</productname>
     is trying to create (4011376640 bytes in this example).
     This is only likely to happen if you have set <literal>shared_memory_type</literal>
     to <literal>sysv</literal>.  In that case, you
     can try starting the server with a smaller-than-normal number of
     buffers (<xref linkend="guc-shared-buffers"/>), or
     reconfigure your kernel to increase the allowed shared memory
     size. You might also see this message when trying to start multiple
     servers on the same machine, if their total space requested
     exceeds the kernel limit.
    </para>

    <para>
     An error like:
<screen>
FATAL:  could not create semaphores: No space left on device
DETAIL:  Failed system call was semget(5440126, 17, 03600).
</screen>
     does <emphasis>not</emphasis> mean you've run out of disk
     space. It means your kernel's limit on the number of <systemitem
     class="osname">System V</systemitem> semaphores is smaller than the number
     <productname>PostgreSQL</productname> wants to create. As above,
     you might be able to work around the problem by starting the
     server with a reduced number of allowed connections
     (<xref linkend="guc-max-connections"/>), but you'll eventually want to
     increase the kernel limit.
    </para>

    <para>
     Details about configuring <systemitem class="osname">System V</systemitem>
     <acronym>IPC</acronym> facilities are given in <xref linkend="sysvipc"/>.
    </para>
   </sect2>

   <sect2 id="client-connection-problems">
    <title>Client Connection Problems</title>

    <para>
     Although the error conditions possible on the client side are quite
     varied and application-dependent, a few of them might be directly
     related to how the server was started. Conditions other than
     those shown below should be documented with the respective client
     application.
    </para>

    <para>
<screen>
psql: error: connection to server at "server.joe.com" (123.123.123.123), port 5432 failed: Connection refused
        Is the server running on that host and accepting TCP/IP connections?
</screen>
     This is the generic <quote>I couldn't find a server to talk
     to</quote> failure. It looks like 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