</para>

       <para>
        It is possible to change all but <varname>SHMMNI</varname> on the fly, using
        <application>sysctl</application>.  But it's still best to set up your preferred
        values via <filename>/etc/sysctl.conf</filename>, so that the values will be
        kept across reboots.
       </para>

      </listitem>
     </varlistentry>

     <varlistentry>
      <term><systemitem class="osname">Solaris</systemitem></term>
      <term><systemitem class="osname">illumos</systemitem></term>
      <listitem>
       <para>
        The default shared memory and semaphore settings are usually good enough for most
        <productname>PostgreSQL</productname> applications.  Solaris defaults
        to a <varname>SHMMAX</varname> of one-quarter of system <acronym>RAM</acronym>.
        To further adjust this setting, use a project setting associated
        with the <literal>postgres</literal> user.  For example, run the
        following as <literal>root</literal>:
<programlisting>
projadd -c "PostgreSQL DB User" -K "project.max-shm-memory=(privileged,8GB,deny)" -U postgres -G postgres user.postgres
</programlisting>
       </para>

       <para>
        This command adds the <literal>user.postgres</literal> project and
        sets the shared memory maximum for the <literal>postgres</literal>
        user to 8GB, and takes effect the next time that user logs
        in, or when you restart <productname>PostgreSQL</productname> (not reload).
        The above assumes that <productname>PostgreSQL</productname> is run by
        the <literal>postgres</literal> user in the <literal>postgres</literal>
        group.  No server reboot is required.
       </para>

       <para>
        Other recommended kernel setting changes for database servers which will
        have a large number of connections are:
<programlisting>
project.max-shm-ids=(priv,32768,deny)
project.max-sem-ids=(priv,4096,deny)
project.max-msg-ids=(priv,4096,deny)
</programlisting>
       </para>

       <para>
        Additionally, if you are running <productname>PostgreSQL</productname>
        inside a zone, you may need to raise the zone resource usage
        limits as well.  See "Chapter2:  Projects and Tasks" in the
        <citetitle>System Administrator's Guide</citetitle> for more
        information on <literal>projects</literal> and <command>prctl</command>.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>

  </sect2>

  <sect2 id="systemd-removeipc">
   <title>systemd RemoveIPC</title>

   <indexterm>
    <primary>systemd</primary>
    <secondary>RemoveIPC</secondary>
   </indexterm>

   <para>
    If <productname>systemd</productname> is in use, some care must be taken
    that IPC resources (including shared memory) are not prematurely
    removed by the operating system.  This is especially of concern when
    installing PostgreSQL from source.  Users of distribution packages of
    PostgreSQL are less likely to be affected, as
    the <literal>postgres</literal> user is then normally created as a system
    user.
   </para>

   <para>
    The setting <literal>RemoveIPC</literal>
    in <filename>logind.conf</filename> controls whether IPC objects are
    removed when a user fully logs out.  System users are exempt.  This
    setting defaults to on in stock <productname>systemd</productname>, but
    some operating system distributions default it to off.
   </para>

   <para>
    A typical observed effect when this setting is on is that shared memory
    objects used for parallel query execution are removed at apparently random
    times, leading to errors and warnings while attempting to open and remove
    them, like
<screen>
WARNING:  could not remove shared memory segment "/PostgreSQL.1450751626": No such file or directory
</screen>
    Different types of IPC objects (shared memory vs. semaphores, System V
    vs. POSIX) are treated slightly differently
    by <productname>systemd</productname>, so one