/var/log/pgsql_log 86400
</programlisting>
  </para>

  <para>
   You can combine these approaches by setting up <application>logrotate</application>
   to collect log files produced by <productname>PostgreSQL</productname> built-in
   logging collector.  In this case, the logging collector defines the names and
   location of the log files, while <application>logrotate</application>
   periodically archives these files.  When initiating log rotation,
   <application>logrotate</application> must ensure that the application
   sends further output to the new file.  This is commonly done with a
   <literal>postrotate</literal> script that sends a <literal>SIGHUP</literal>
   signal to the application, which then reopens the log file.
   In <productname>PostgreSQL</productname>, you can run <command>pg_ctl</command>
   with the <literal>logrotate</literal> option instead.  When the server receives
   this command, the server either switches to a new log file or reopens the
   existing file, depending on the logging configuration
   (see <xref linkend="runtime-config-logging-where"/>).
  </para>

  <note>
   <para>
    When using static log file names, the server might fail to reopen the log
    file if the max open file limit is reached or a file table overflow occurs.
    In this case, log messages are sent to the old log file until a
    successful log rotation. If <application>logrotate</application> is
    configured to compress the log file and delete it, the server may lose
    the messages logged in this time frame. To avoid this issue, you can
    configure the logging collector to dynamically assign log file names
    and use a <literal>prerotate</literal> script to ignore open log files.
    </para>
  </note>

  <para>
   Another production-grade approach to managing log output is to
   send it to <application>syslog</application> and let
   <application>syslog</application> deal with file rotation. To do this, set the
   configuration parameter <varname>log_destination</varname> to <literal>syslog</literal>
   (to log to <application>syslog</application> only) in
   <filename>postgresql.conf</filename>. Then you can send a <literal>SIGHUP</literal>
   signal to the <application>syslog</application> daemon whenever you want to force it
   to start writing a new log file.  If you want to automate log
   rotation, the <application>logrotate</application> program can be
   configured to work with log files from
   <application>syslog</application>.
  </para>

  <para>
   On many systems, however, <application>syslog</application> is not very reliable,
   particularly with large log messages; it might truncate or drop messages
   just when you need them the most.  Also, on <productname>Linux</productname>,
   <application>syslog</application> will flush each message to disk, yielding poor
   performance.  (You can use a <quote><literal>-</literal></quote> at the start of the file name
   in the <application>syslog</application> configuration file to disable syncing.)
  </para>

  <para>
   Note that all the solutions described above take care of starting new
   log files at configurable intervals, but they do not handle deletion
   of old, no-longer-useful log files.  You will probably want to set
   up a batch job to periodically delete old log files.  Another possibility
   is to configure the rotation program so that old log files are overwritten
   cyclically.
  </para>

  <para>
   <ulink url="https://pgbadger.darold.net/"><productname>pgBadger</productname></ulink>
   is an external project that does sophisticated log file analysis.
   <ulink
   url="https://bucardo.org/check_postgres/"><productname>check_postgres</productname></ulink>
   provides Nagios alerts when important messages appear in the log
   files, as well as detection of many other extraordinary conditions.
  </para>
 </sect1>
</chapter>