It's 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 thrown
away every so often.
If you simply direct the postmaster's stderr into a
file, the only way to truncate the log file is to stop and restart
the postmaster. This may be OK for development setups but you won't
want to run a production server that way.
The simplest 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
syslog to 2 (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
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. You may find it more useful to pipe the
postmaster's stderr to some type of
log rotation script. If you start the postmaster with
pg_ctl, then the postmaster's stderr
is already redirected to stdout, so you just need a
pg_ctl start | logrotate
The PostgreSQL distribution doesn't include a suitable
log rotation program, but there are many available on the net;
one is included in the Apache distribution, for example.