It is a good idea to save the database server's log output
somewhere, rather than just routing it to /dev/null.
The log output is invaluable when it comes time to diagnose
problems. However, the log output tends to be voluminous
(especially at higher debug levels) and you won't want to save it
indefinitely. You need to "rotate" 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 stderr of the
edb-postmaster into a
file, you will have log output, but
the only way to truncate the log file is to stop and restart
the edb-postmaster. This may be OK if you are using
EnterpriseDB in a development environment,
but few production servers would find this behavior acceptable.
A better approach is to send the edb-postmaster's
stderr output to some type of log rotation program.
There is a built-in log rotation program, which you can use by
setting the configuration parameter redirect_stderr to
true in postgresql.conf. The control
parameters for this program are described in Section 30.4.7.1.
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 rotatelogs
tool included in the Apache distribution
can be used with EnterpriseDB. To do this,
just pipe the edb-postmaster's
stderr output to the desired program.
If you start the server with
pg_ctl, then stderr
is already redirected to stdout, so you just need a
pipe command:
pg_ctl start | rotatelogs /var/log/pgsql_log 86400
Another production-grade approach to managing log output is to
send it all to syslog and let
syslog deal with file rotation. To do this, set the
configuration parameter log_destination to syslog
(to log to syslog only) in
postgresql.conf. Then you can send a SIGHUP
signal to the syslog daemon whenever you want to force it
to start writing a new log file. If you want to automate log
rotation, the logrotate program can be
configured to work with log files from
syslog.
On many systems, however, syslog is not very reliable,
particularly with large log messages; it may truncate or drop messages
just when you need them the most. Also, on linux,
syslog will sync each message to disk, yielding poor
performance. (You can use a - at the start of the file name
in the syslog config file to disable this behavior.)
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-interesting log files. You will also want to set
up a batch job to periodically delete old log files.