<command>ulimit -l</command>.
   </para>

   <para>
    The default behavior for huge pages in
    <productname>PostgreSQL</productname> is to use them when possible, with
    the system's default huge page size, and
    to fall back to normal pages on failure. To enforce the use of huge
    pages, you can set <xref linkend="guc-huge-pages"/>
    to <literal>on</literal> in <filename>postgresql.conf</filename>.
    Note that with this setting <productname>PostgreSQL</productname> will fail to
    start if not enough huge pages are available.
   </para>

   <para>
    For a detailed description of the <productname>Linux</productname> huge
    pages feature have a look
    at <ulink url="https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt"></ulink>.
   </para>

  </sect2>
 </sect1>


 <sect1 id="server-shutdown">
  <title>Shutting Down the Server</title>

  <indexterm zone="server-shutdown">
   <primary>shutdown</primary>
  </indexterm>

  <para>
   There are several ways to shut down the database server.
   Under the hood, they all reduce to sending a signal to the supervisor
   <command>postgres</command> process.
  </para>

  <para>
   If you are using a pre-packaged version
   of <productname>PostgreSQL</productname>, and you used its provisions
   for starting the server, then you should also use its provisions for
   stopping the server.  Consult the package-level documentation for
   details.
  </para>

  <para>
   When managing the server directly, you can control the type of shutdown
   by sending different signals to the <command>postgres</command>
   process:

   <variablelist>
    <varlistentry>
     <term><systemitem>SIGTERM</systemitem><indexterm><primary>SIGTERM</primary></indexterm></term>
     <listitem>
      <para>
       This is the <firstterm>Smart Shutdown</firstterm> mode.
       After receiving <systemitem>SIGTERM</systemitem>, the server
       disallows new connections, but lets existing sessions end their
       work normally. It shuts down only after all of the sessions terminate.
       If the server is in recovery when a smart
       shutdown is requested, recovery and streaming replication will be
       stopped only after all regular sessions have terminated.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><systemitem>SIGINT</systemitem><indexterm><primary>SIGINT</primary></indexterm></term>
     <listitem>
      <para>
       This is the <firstterm>Fast Shutdown</firstterm> mode.
       The server disallows new connections and sends all existing
       server processes <systemitem>SIGTERM</systemitem>, which will cause them
       to abort their current transactions and exit promptly. It then
       waits for all server processes to exit and finally shuts down.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><systemitem>SIGQUIT</systemitem><indexterm><primary>SIGQUIT</primary></indexterm></term>
     <listitem>
      <para>
      This is the <firstterm>Immediate Shutdown</firstterm> mode.
      The server will send <systemitem>SIGQUIT</systemitem> to all child
      processes and wait for them to terminate.  If any do not terminate
      within 5 seconds, they will be sent <systemitem>SIGKILL</systemitem>.
      The supervisor server process exits as soon as all child processes have
      exited, without doing normal database shutdown processing.
      This will lead to recovery (by
      replaying the WAL log) upon next start-up. This is recommended
      only in emergencies.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   The <xref linkend="app-pg-ctl"/> program provides a convenient
   interface for sending these signals to shut down the server.
   Alternatively, you can send the signal directly using <command>kill</command>
   on non-Windows systems.
   The <acronym>PID</acronym> of the <command>postgres</command> process can be
   found using the <command>ps</command> program,