wegster at mindcore.net
Sun Dec 28 10:24:08 PST 2003
Gerard Samuel wrote:
> On Sunday 28 December 2003 12:36 pm, Lowell Gilbert wrote:
>>Gerard Samuel <fbsd-questions at trini0.org> writes:
>>>In particular, Im looking to see if there is a "FreeBSD" way in
>>>rotating PostgreSQL logs.
>>>Any advise would be appreciated.
>>newsyslog(8) is part of the base system...
> Yes, Im familiar with newsyslog, but Im not sure how it will play with
> rotating PostgreSQL's log file, as PostgreSQL seems to need some extra TLC
> when rotating the log while PostgreSQL is running.
> Ill have to let that sink in the brain, before I try messing with it.
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
Just a guess here, but what the problem likely is is that Postgres keeps
a file descriptor open to it's logfile, which means that 'simple' log
rotation, eg just moving the original logfile to a backup name or
gzipped file will break the logging as pg won't have a valid file
descriptor any more. This one's bit a project I worked on forever ago
(on a production system! :-( ) running Solaris and Sybase...
The easy solution is to see if any of the log rotation scripts have the
'right' behavior...if not, you can write your own script to do it, test
it by rotating the logs and then intentionally doing something to
produce log output (depending on your log level)...if you get the log
output, everything's happy. What it should be doing is this (and a side
effect is you shouldn't run into log problems on other apps either):
1. Copy the log file locally, using whatever naming convention you
want, eg logname.(massaged date/time stamp like $(date | cut -f' '))
2. Truncate the existing log via cat /dev/null > original logfile .
This allows the logging progam to continue to log without an invalid fd..
3. gzip or move the copied logfile to wherever, gzip it etc..
This is a simple solution, and has the potential to lose a few log
entries due to the time from the completion of the original log copy
until the original log file truncation is completed, but should be fine
for home, non critical or low usage (meaning not logging 1000
messages/minute) log files....there's probably a better way to do this,
probably logging via a pipe, but I don't know the specifics offhand...
More information about the freebsd-questions