I think I may have found an answer to my own problem:
> What is a good solution for rotating postgresql log files?
> I'm running 'Linux 2.2.16-22smp #1 SMP i686 unknown' and a solution that
> was proposed to me was to use cron and a program called logrotate:
> Unfortunately, after replacing/rotating/compressing the database log
> file, the new log file remains empty. I have a feeling that postgres has
> lost the reference to the original log file and that the new log data is
> lost into the void.
The (new) contents of /etc/logrotate.d/postgres:
# start
/var/log/postgresql.log {
compress
rotate 10
create 0664 postgres postgres
size=10000k
weekly
sharedscripts
postrotate
/etc/rc.d/init.d/postgresql restart
endscript
}
#end
From the logrotate man page:
size size
Log files are rotated when they grow bigger then
size bytes.
weekly
Log files are rotated if the current weekday is
less then the weekday of the last rotation or if
more then a week has passed since the last rota
tion.
postrotate/endscript
The lines between postrotate and endscript (both of
which must appear on lines by themselves) are exe
cuted after the log file is rotated. These direc
tives may only appear inside of a log file defini
tion. See prerotate as well.
sharedscripts
Normally, prescript and postscript scripts are run
for each log which is rotated, meaning that a sin
gle script may be run multiple times for log file
entries which match multiple files (such as the
/var/log/news/* example). If sharedscript is speci
fied, the scripts are only run once, no matter how
many logs match the wildcarded pattern. A side
effect of this option is that the scripts are
always executed, even if no logs are rotated (if it
is not specified, the scripts are run only if logs
are actually rotated) (this overrides the noshared
scripts option).
Any comments about this setup are welcome. :)
Jelle Ouwerkerk
Software Developer
Openface Internet Inc.
Montreal, Quebec, Canada
http://www.openface.ca
