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 might observe that some IPC
    resources are not removed in the same way as others.  But it is not
    advisable to rely on these subtle differences.
   </para>

   <para>
    A <quote>user logging out</quote> might happen as part of a maintenance
    job or manually when an administrator logs in as
    the <literal>postgres</literal> user or something similar, so it is hard
    to prevent in general.
   </para>

   <para>
    What is a <quote>system user</quote> is determined
    at <productname>systemd</productname> compile time from
    the <symbol>SYS_UID_MAX</symbol> setting
    in <filename>/etc/login.defs</filename>.
   </para>

   <para>
    Packaging and deployment scripts should be careful to create
    the <literal>postgres</literal> user as a system user by
    using <literal>useradd -r</literal>, <literal>adduser --system</literal>,
    or equivalent.
   </para>

   <para>
    Alternatively, if the user account was created incorrectly or cannot be
    changed, it is recommended to set
<programlisting>
RemoveIPC=no
</programlisting>
    in <filename>/etc/systemd/logind.conf</filename> or another appropriate
    configuration file.
   </para>

   <caution>
    <para>
     At least one of these two things has to be ensured, or the PostgreSQL
     server will be very unreliable.
    </para>
   </caution>
  </sect2>

  <sect2 id="kernel-resources-limits">
   <title>Resource Limits</title>

   <para>
    Unix-like operating systems enforce various kinds of resource limits
    that might interfere with the operation of your
    <productname>PostgreSQL</productname> server. Of particular
    importance are limits on the number of processes per user, the
    number of open files per process, and the amount of memory available
    to each process. Each of these have a <quote>hard</quote> and a
    <quote>soft</quote> limit. The soft limit is what actually counts
    but it can be changed by the user up to the hard limit. The hard
    limit can only be changed by the root user. The system call
    <function>setrlimit</function> is responsible for setting these
    parameters. The shell's built-in command <command>ulimit</command>
    (Bourne shells) or <command>limit</command> (<application>csh</application>) is
    used to control the resource limits from the command line. On
    BSD-derived systems the file <filename>/etc/login.conf</filename>
    controls the various resource limits set during login. See the
    operating system documentation for details. The relevant
    parameters are <varname>maxproc</varname>,
    <varname>openfiles</varname>, and <varname>datasize</varname>. For
    example:
<programlisting>
default:\
...
        :datasize-cur=256M:\
        :maxproc-cur=256:\
        :openfiles-cur=256:\
...
</programlisting>
    (<literal>-cur</literal> is the soft limit.  Append
    <literal>-max</literal> to set the hard limit.)
   </para>

   <para>
    Kernels can also have system-wide limits on some resources.
    <itemizedlist>