24.3. Log File Maintenance
It is a good idea to save the database server's log output
somewhere, rather than just discarding it via
The log output is invaluable when diagnosing
problems. However, the log output tends to be voluminous
(especially at higher debug levels) so you won't want to save it
indefinitely. You need to
the log files so that
new log files are started and old ones removed after a reasonable
period of time.
If you simply direct the
file, you will have log output, but
the only way to truncate the log file is to stop and restart
the server. This might be acceptable if you are using
in a development environment,
but few production servers would find this behavior acceptable.
A better approach is to send the server's
output to some type of log rotation program.
There is a built-in log rotation facility, which you can use by
setting the configuration parameter
. The control
parameters for this program are described in
. You can also use this approach
to capture the log data in machine readable
(comma-separated values) format.
Alternatively, you might prefer to use an external log rotation
program if you have one that you are already using with other
server software. For example, the
tool included in the
can be used with
. One way to
do this is to pipe the server's
output to the desired program.
If you start the server with
is already redirected to
, so you just need a
pipe command, for example:
pg_ctl start | rotatelogs /var/log/pgsql_log 86400
You can combine these approaches by setting up
to collect log files produced by
logging collector. In this case, the logging collector defines the names and
location of the log files, while
periodically archives these files. When initiating log rotation,
must ensure that the application
sends further output to the new file. This is commonly done with a
script that sends a
signal to the application, which then reopens the log file.
, you can run
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
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
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
script to ignore open log files.
Another production-grade approach to managing log output is to
send it to
deal with file rotation. To do this, set the
(to log to
. Then you can send a
signal to the
daemon whenever you want to force it
to start writing a new log file. If you want to automate log
program can be
configured to work with log files from
On many systems, however,
is not very reliable,
particularly with large log messages; it might truncate or drop messages
just when you need them the most. Also, on
will flush each message to disk, yielding poor
performance. (You can use a
at the start of the file name
configuration file to disable syncing.)
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.
pgBadger is an external project that does sophisticated log file analysis. check_postgres provides Nagios alerts when important messages appear in the log files, as well as detection of many other extraordinary conditions.