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 stderr of the postmaster 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 the configurations parameter syslog to 2 (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. You may find it more useful to pipe
the stderr of the postmaster to some type of log rotation program.
If you start the server with pg_ctl,
then the stderr of the postmaster is already redirected to stdout, so you just need a pipe command:

pg_ctl start | logrotate

The PostgreSQL distribution
doesn't include a suitable log rotation program, but there are
many available on the Internet; one is included in the Apache
distribution, for example.