applications</entry>
       </row>

       <row>
        <entry><varname>SEMMNI</varname></entry>
        <entry>Maximum number of semaphore identifiers (i.e., sets)</entry>
        <entry>at least <literal>ceil(num_os_semaphores / 16)</literal> plus room for other applications</entry>
       </row>

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

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

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

       <row>
        <entry><varname>SEMVMX</varname></entry>
        <entry>Maximum value of semaphore</entry>
        <entry>at least 1000 (The default is often 32767; do not change unless necessary)</entry>
       </row>

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

   <para>
    <productname>PostgreSQL</productname> requires a few bytes of System V shared memory
    (typically 48 bytes, on 64-bit platforms) for each copy of the server.
    On most modern operating systems, this amount can easily be allocated.
    However, if you are running many copies of the server or you explicitly
    configure the server to use large amounts of System V shared memory (see
    <xref linkend="guc-shared-memory-type"/> and <xref
    linkend="guc-dynamic-shared-memory-type"/>), it may be necessary to
    increase <varname>SHMALL</varname>, which is the total amount of System V shared
    memory system-wide.  Note that <varname>SHMALL</varname> 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</varname>), which should be at most
    approximately 32 bytes for <productname>PostgreSQL</productname> (it is
    usually just 1). The maximum number of segments system-wide
    (<varname>SHMMNI</varname>) or per-process (<varname>SHMSEG</varname>) are unlikely
    to cause a problem unless your system has them set to zero.
   </para>

   <para>
    When using System V semaphores,
    <productname>PostgreSQL</productname> uses one semaphore per allowed connection
    (<xref linkend="guc-max-connections"/>), allowed autovacuum worker process
    (<xref linkend="guc-autovacuum-worker-slots"/>), allowed WAL sender process
    (<xref linkend="guc-max-wal-senders"/>), allowed background
    process (<xref linkend="guc-max-worker-processes"/>), etc., in sets of 16.
    The runtime-computed parameter <xref linkend="guc-num-os-semaphores"/>
    reports the number of semaphores required.  This parameter can be viewed
    before starting the server with a <command>postgres</command> command like:
<programlisting>
$ <userinput>postgres -D $PGDATA -C num_os_semaphores</userinput>
</programlisting>
   </para>

   <para>
    Each set of 16 semaphores 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</varname>, which consequently must be at least
    as high as <literal>num_os_semaphores</literal> plus one extra for
    each set of 16 required semaphores (see the formula in <xref
    linkend="sysvipc-parameters"/>).  The parameter <varname>SEMMNI</varname>
    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(num_os_semaphores / 16)</literal>.
    Lowering the number
    of allowed connections is a temporary workaround for failures,
    which are usually confusingly worded <quote>No