(Linux, FreeBSD) or <function>copyfile</function>
        (macOS) system calls, giving the kernel the opportunity to share disk
        blocks or push work down to lower layers on some file systems.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-notify-queue-pages" xreflabel="max_notify_queue_pages">
      <term><varname>max_notify_queue_pages</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>max_notify_queue_pages</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies the maximum amount of allocated pages for
        <xref linkend="sql-notify"/> / <xref linkend="sql-listen"/> queue.
        The default value is 1048576. For 8 KB pages it allows to consume
        up to 8 GB of disk space.
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
     </sect2>

     <sect2 id="runtime-config-resource-kernel">
     <title>Kernel Resource Usage</title>

     <variablelist>
     <varlistentry id="guc-max-files-per-process" xreflabel="max_files_per_process">
      <term><varname>max_files_per_process</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>max_files_per_process</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Sets the maximum number of open files each server subprocess is
        allowed to open simultaneously;  files already opened in the
        postmaster are not counted toward this limit. The default is one
        thousand files.
       </para>
       <para>
        If the kernel is enforcing
        a safe per-process limit, you don't need to worry about this setting.
        But on some platforms (notably, most BSD systems), the kernel will
        allow individual processes to open many more files than the system
        can actually support if many processes all try to open
        that many files. If you find yourself seeing <quote>Too many open
        files</quote> failures, try reducing this setting.
        This parameter can only be set at server start.
       </para>
      </listitem>
     </varlistentry>
     </variablelist>
    </sect2>


    <sect2 id="runtime-config-resource-background-writer">
     <title>Background Writer</title>

     <para>
      There is a separate server
      process called the <firstterm>background writer</firstterm>, whose function
      is to issue writes of <quote>dirty</quote> (new or modified) shared
      buffers.  When the number of clean shared buffers appears to be
      insufficient, the background writer writes some dirty buffers to the
      file system and marks them as clean.  This reduces the likelihood
      that server processes handling user queries will be unable to find
      clean buffers and have to write dirty buffers themselves.
      However, the background writer does cause a net overall
      increase in I/O load, because while a repeatedly-dirtied page might
      otherwise be written only once per checkpoint interval, the
      background writer might write it several times as it is dirtied
      in the same interval.  The parameters discussed in this subsection
      can be used to tune the behavior for local needs.
     </para>

     <variablelist>
      <varlistentry id="guc-bgwriter-delay" xreflabel="bgwriter_delay">
       <term><varname>bgwriter_delay</varname> (<type>integer</type>)
       <indexterm>
        <primary><varname>bgwriter_delay</varname> configuration parameter</primary>
       </indexterm>
       </term>
       <listitem>
        <para>
         Specifies the delay between activity rounds for the
         background writer.  In each round the writer issues writes
         for some number of dirty buffers (controllable by the
         following parameters).  It then sleeps for
         the length of <varname>bgwriter_delay</varname>, and repeats.
         When there are no dirty