On Tue, Jan 13, 2009 at 4:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> I have perfectly good log rotation utility that exists on my OS. (yes I
>> am aware of the possibility of losing a log entry when using logrotate).
>
> You might think you do, but it won't work with PG; external rotators
> only work with programs that respond to SIGHUP by re-opening their log
> files.
If that were true, then we would surely want to change it so that it
always re-opens the log file in response to SIGHUP. But I don't think
it is - it seems we have pg_rotate_logfile() for that purpose.
Standard utilities like the logrotate that ships with Fedora can run
an external command after rotating the log file, and that external
command can arrange to invoke pg_rotate_logfile(). Admittedly, this
may be a little bit clunky: maybe we should always reopen the logfiles
on receipt of a SIGHUP, since there doesn't seem to be much of a
downside.
(It's true that if we go that route more people will set up external
log rotators to SIGHUP PostgreSQL, and that could increase the chance
of SIGHUP causing the postgresql.conf file to be reloaded when the
user wasn't quite ready, but that doesn't seem to be much of an
argument for not doing it. Apache does the same thing, and on one
occasion it took down my entire web server, but I don't blame the
Apache project for the fact that I left my configuration in a
screwed-up state before taking off for the weekend.)
Automatically adding the date is a much bigger problem for an external
rotator. It means that there is no way to get a constant filename. I
don't think there's a clean way to handle that situation using Red
Hat's logrotate, which may be why Red Hat's out-of-the-box PG
configuration doesn't handle PG logfiles the way it handles all of its
other log files, which may be why I wasn't really aware that PG even
HAD a log file until about six months ago.
Suggested patch attached.
...Robert