Home • Explore • Blog • CI
☰



postgresql
100th chunk of `doc/src/sgml/config.sgml`
2ab853076203d5259271fb87bb2f2751401936b570d2f1520000000100000fa7
 should
         register an event source and its library with the operating
         system so that the Windows Event Viewer can display event
         log messages cleanly.
         See <xref linkend="event-log-registration"/> for details.
        </para>
       </note>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-logging-collector" xreflabel="logging_collector">
      <term><varname>logging_collector</varname> (<type>boolean</type>)
      <indexterm>
       <primary><varname>logging_collector</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
         This parameter enables the <firstterm>logging collector</firstterm>, which
         is a background process that captures log messages
         sent to <systemitem>stderr</systemitem> and redirects them into log files.
         This approach is often more useful than
         logging to <application>syslog</application>, since some types of messages
         might not appear in <application>syslog</application> output.  (One common
         example is dynamic-linker failure messages; another is error messages
         produced by scripts such as <varname>archive_command</varname>.)
         This parameter can only be set at server start.
       </para>

       <note>
        <para>
         It is possible to log to <systemitem>stderr</systemitem> without using the
         logging collector; the log messages will just go to wherever the
         server's <systemitem>stderr</systemitem> is directed.  However, that method is
         only suitable for low log volumes, since it provides no convenient
         way to rotate log files.  Also, on some platforms not using the
         logging collector can result in lost or garbled log output, because
         multiple processes writing concurrently to the same log file can
         overwrite each other's output.
        </para>
       </note>

       <note>
        <para>
          The logging collector is designed to never lose messages.  This means
          that in case of extremely high load, server processes could be
          blocked while trying to send additional log messages when the
          collector has fallen behind.  In contrast, <application>syslog</application>
          prefers to drop messages if it cannot write them, which means it
          may fail to log some messages in such cases but it will not block
          the rest of the system.
        </para>
       </note>

      </listitem>
     </varlistentry>

     <varlistentry id="guc-log-directory" xreflabel="log_directory">
      <term><varname>log_directory</varname> (<type>string</type>)
      <indexterm>
       <primary><varname>log_directory</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        When <varname>logging_collector</varname> is enabled,
        this parameter determines the directory in which log files will be created.
        It can be specified as an absolute path, or relative to the
        cluster data directory.
        This parameter can only be set in the <filename>postgresql.conf</filename>
        file or on the server command line.
        The default is <literal>log</literal>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-log-filename" xreflabel="log_filename">
      <term><varname>log_filename</varname> (<type>string</type>)
      <indexterm>
       <primary><varname>log_filename</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        When <varname>logging_collector</varname> is enabled,
        this parameter sets the file names of the created log files.  The value
        is treated as a <function>strftime</function> pattern,
        so <literal>%</literal>-escapes can be used to specify time-varying
        file names.  (Note that if there are
        any time-zone-dependent <literal>%</literal>-escapes,
Title: Logging Collector Details and Log File Configuration
Summary
This section provides detailed information about the `logging_collector` parameter, which enables a background process that captures log messages sent to stderr and redirects them into log files. It highlights the advantages and disadvantages of using the logging collector versus syslog. The section also covers the `log_directory` parameter, which specifies the directory where log files are created when the logging collector is enabled. Finally, it briefly introduces the `log_filename` parameter used to set the file names of the created log files.