runtime.sgml

PostgreSQL 8.1.4的源码 适用于Linux下的开源数据库系统

     redirecting standard output or standard error) and see what error
     messages appear. Below we explain some of the most common error
     messages in more detail.
    </para>

    <para>
<screen>
LOG:  could not bind IPv4 socket: Address already in use
HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
FATAL:  could not create TCP/IP listen socket
</screen>
     This usually means just what it suggests: you tried to start
     another <command>postmaster</command> on the same port where one is already running.
     However, if the kernel error message is not <computeroutput>Address
     already in use</computeroutput> or some variant of that, there may
     be a different problem. For example, trying to start a <command>postmaster</command>
     on a reserved port number may draw something like:
<screen>
$ <userinput>postmaster -p 666</userinput>
LOG:  could not bind IPv4 socket: Permission denied
HINT:  Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL:  could not create TCP/IP listen socket
</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). Or it could
     mean that you do not have System-V-style shared memory support
     configured into your kernel at all. As a temporary workaround, you
     can try starting the server with a smaller-than-normal number of
     buffers (<xref linkend="guc-shared-buffers">). You will eventually want
     to reconfigure your kernel to increase the allowed shared memory
     size. You may 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</> semaphores is smaller than the number
     <productname>PostgreSQL</productname> wants to create. As above,
     you may 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>
     If you get an <quote>illegal system call</> error, it is likely that
     shared memory or semaphores are not supported in your kernel at
     all. In that case your only option is to reconfigure the kernel to
     enable these features.
    </para>

    <para>
     Details about configuring <systemitem class="osname">System V</>
     <acronym>IPC</> 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 up. Conditions other than
     those shown below should be documented with the respective client
     application.
    </para>

    <para>
<screen>
psql: could not connect to server: Connection refused
        Is the server running on host "server.joe.com" and accepting
        TCP/IP connections on port 5432?
</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 the server to allow TCP/IP connections.
    </para>

    <para>
     Alternatively, you'll get this when attempting Unix-domain socket
     communication to a local server:
<screen>
psql: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
</screen>
    </para>

    <para>
     The last line is useful in verifying that the client is trying to
     connect to the right place. If there is in fact no server
     running 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> may
     indicate more fundamental problems, like lack of network
     connectivity.
    </para>
   </sect2>
  </sect1>

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

  <para>
   A large <productname>PostgreSQL</> installation can quickly exhaust
   various operating system resource limits. (On some systems, the
   factory defaults are so low that you don't even need a really
   <quote>large</> installation.) If you have encountered this kind of
   problem, keep reading.
  </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>
    Shared memory and semaphores are collectively referred to as
    <quote><systemitem class="osname">System V</>
    <acronym>IPC</></quote> (together with message queues, which are not
    relevant for <productname>PostgreSQL</>). Almost all modern
    operating systems provide these features, but not all of them have
    them turned on or sufficiently sized by default, especially systems
    with BSD heritage. (For the <systemitem class="osname">Windows</>,
    <systemitem class="osname">QNX</> and <systemitem class="osname">BeOS</>
    ports, <productname>PostgreSQL</> provides its own replacement
    implementation of these facilities.)
   </para>

   <para>
    The complete lack of these facilities is usually manifested by an
    <errorname>Illegal system call</> error upon server start. In
    that case there's nothing left to do but to reconfigure your
    kernel.  <productname>PostgreSQL</> won't work without them.
   </para>

   <para>
    When <productname>PostgreSQL</> exceeds one of the various hard
    <acronym>IPC</> limits, the server will refuse to start and
    should leave an instructive error message describing the problem
    encountered and what to do about it. (See also <xref
    linkend="postmaster-start-failures">.) The relevant kernel
    parameters are named consistently across different systems; <xref
    linkend="sysvipc-parameters"> gives an overview. The methods to set
    them, however, vary. Suggestions for some platforms are given below.
    Be warned that it is often necessary to reboot your machine, and
    possibly even recompile the kernel, to change these settings.
   </para>


   <table id="sysvipc-parameters">
    <title><systemitem class="osname">System V</> <acronym>IPC</> parameters</>

    <tgroup cols="3">
     <thead>
      <row>
       <entry>Name</>
       <entry>Description</>
       <entry>Reasonable values</>
      </row>
     </thead>

     <tbody>
      <row>
       <entry><varname>SHMMAX</></>
       <entry>Maximum size of shared memory segment (bytes)</>
       <entry>at least several megabytes (see text)</entry>
      </row>

      <row>
       <entry><varname>SHMMIN</></>
       <entry>Minimum size of shared memory segment (bytes)</>
       <entry>1</>
      </row>

      <row>
       <entry><varname>SHMALL</></>
       <entry>Total amount of shared memory available (bytes or pages)</>
       <entry>if bytes, same as <varname>SHMMAX</varname>; if pages, <literal>ceil(SHMMAX/PAGE_SIZE)</literal></>
      </row>

      <row>
       <entry><varname>SHMSEG</></>
       <entry>Maximum number of shared memory segments per process</>
       <entry>only 1 segment is needed, but the default is much higher</>
      </row>

       <row>
        <entry><varname>SHMMNI</></>
        <entry>Maximum number of shared memory segments system-wide</>
        <entry>like <varname>SHMSEG</> plus room for other applications</>
       </row>

       <row>
        <entry><varname>SEMMNI</></>
        <entry>Maximum number of semaphore identifiers (i.e., sets)</>
        <entry>at least <literal>ceil(max_connections / 16)</literal></>
       </row>

       <row>
        <entry><varname>SEMMNS</></>
        <entry>Maximum number of semaphores system-wide</>
        <entry><literal>ceil(max_connections / 16) * 17</literal> plus room for other applications</>
       </row>

       <row>
        <entry><varname>SEMMSL</></>
        <entry>Maximum number of semaphores per set</>
        <entry>at least 17</>
       </row>

       <row>
        <entry><varname>SEMMAP</></>
        <entry>Number of entries in semaphore map</>
        <entry>see text</>
       </row>

       <row>
        <entry><varname>SEMVMX</></>
        <entry>Maximum value of semaphore</>
        <entry>at least 1000 (The default is often 32767, don't change unless forced to)</>
       </row>

     </tbody>
    </tgroup>
   </table>


   <para>
    <indexterm><primary>SHMMAX</primary></indexterm> The most important
    shared memory parameter is <varname>SHMMAX</>, the maximum size, in
    bytes, of a shared memory segment. If you get an error message from
    <function>shmget</> like <errorname>Invalid argument</>, it is
    likely that this limit has been exceeded. The size of the required
    shared memory segment varies depending on several
    <productname>PostgreSQL</> configuration parameters, as shown in
    <xref linkend="shared-memory-parameters">.
    You can, as a temporary solution, lower some of those settings to
    avoid the failure.  As a rough approximation, you can estimate the
    required segment size as 500 kB plus the variable amounts shown in
    the table.  (Any error message you might get will include the exact
    size of the failed allocation request.)  While it is possible to get
    <productname>PostgreSQL</> to run with <varname>SHMMAX</> as small as
    1 MB, you need at least 4 MB for acceptable performance, and desirable
    settings are in the tens of megabytes.
   </para>

   <para>
    Some systems also have a limit on the total amount of shared memory in
    the system (<varname>SHMALL</>).  Make sure this is large enough
    for <productname>PostgreSQL</> plus any other applications that
    are using shared memory segments.  (Caution: <varname>SHMALL</>
    is measured in pages rather than bytes on many systems.)
   </para>

   <para>
    Less likely to cause problems is the minimum size for shared
    memory segments (<varname>SHMMIN</>), which should be at most
    approximately 500 kB for <productname>PostgreSQL</> (it is
    usually just 1). The maximum number of segments system-wide
    (<varname>SHMMNI</>) or per-process (<varname>SHMSEG</>) are unlikely
    to cause a problem unless your system has them set to zero.
   </para>

   <para>
    <productname>PostgreSQL</> uses one semaphore per allowed connection
    (<xref linkend="guc-max-connections">), in sets of 16.  Each such set will
    also contain a 17th semaphore which contains a <quote>magic
    number</quote>, to detect collision with semaphore sets used by
    other applications. The maximum number of semaphores in the system
    is set by <varname>SEMMNS</>, which consequently must be at least
    as high as <varname>max_connections</> plus one extra for each 16
    allowed connections (see the formula in <xref
    linkend="sysvipc-parameters">).  The parameter <varname>SEMMNI</>
    determines the limit on the number of semaphore sets that can
    exist on the system at one time.  Hence this parameter must be at
    least <literal>ceil(max_connections / 16)</>. Lowering the number
    of allowed connections is a temporary workaround for failures,
    which are usually confusingly worded <errorname>No space
    left on device</>, from the function <function>semget</>.
   </para>

   <para>
    In some cases it might also be necessary to increase
    <varname>SEMMAP</> to be at least on the order of
    <varname>SEMMNS</>. This parameter defines the size of the semaphore
    resource map, in which each contiguous block of available semaphores
    needs an entry. When a semaphore set is freed it is either added to
    an existing entry that is adjacent to the freed block or it is
    registered under a new map entry. If the map is full, the freed
    semaphores get lost (until reboot). Fragmentation of the semaphore
    space could over time lead to fewer available semaphores than there
    should be.
   </para>

   <para>
    The <varname>SEMMSL</> parameter, which determines how many