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 space
    left on device</quote>, from the function <function>semget</function>.
   </para>

   <para>
    In some cases it might also be necessary to increase
    <varname>SEMMAP</varname> to be at least on the order of
    <varname>SEMMNS</varname>.  If the system has this parameter
    (many do not), it 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>
    Various other settings related to <quote>semaphore undo</quote>, such as
    <varname>SEMMNU</varname> and <varname>SEMUME</varname>, do not affect
    <productname>PostgreSQL</productname>.
   </para>

   <para>
    When using POSIX semaphores, the number of semaphores needed is the
    same as for System V, that is 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.
    On the platforms where this option is preferred, there is no specific
    kernel limit on the number of POSIX semaphores.
   </para>


    <variablelist>
     <varlistentry>
      <term><systemitem class="osname">FreeBSD</systemitem>
      <indexterm><primary>FreeBSD</primary><secondary>IPC configuration</secondary></indexterm>
      </term>
      <listitem>
       <para>
        The default shared memory settings are usually good enough, unless
        you have set <literal>shared_memory_type</literal> to <literal>sysv</literal>.
        System V semaphores are not used on this platform.
       </para>

       <para>
        The default IPC settings can be changed using
        the <command>sysctl</command> or
        <command>loader</command> interfaces.  The following
        parameters can be set using <command>sysctl</command>:
<screen>
<prompt>#</prompt> <userinput>sysctl kern.ipc.shmall=32768</userinput>
<prompt>#</prompt> <userinput>sysctl kern.ipc.shmmax=134217728</userinput>
</screen>
        To make these settings persist over reboots, modify
        <filename>/etc/sysctl.conf</filename>.
       </para>

       <para>
        If you have set <literal>shared_memory_type</literal> to
        <literal>sysv</literal>, you might also want to configure your kernel
        to lock System V shared memory into RAM and prevent it from being paged
        out to swap.  This can be accomplished using the <command>sysctl</command>
        setting <literal>kern.ipc.shm_use_phys</literal>.
       </para>

       <para>