On Oct 26, 2007, at 6:42 PM, Joshua D. Drake wrote:
>>>> If logrotate would work, we'd never have bothered writing our own
>>>> substitute. But there's no way for logrotate to repoint
>>>> postmaster's stderr into other files.
>>
>>> Uh... can't we just use copytruncate with logroate?
>>
>> How's that going to reset the offsets in the stderr file descriptors
>> of the various PG processes? There might be some platforms and
>> configurations where it will work, but I wouldn't tout it as a
>> portable approach. I'd also suppose that there are race conditions
>> involved: you'll either lose or duplicate messages that are emitted
>> while copytruncate works.
>
> Yeah, we have seen that, where the log will be missing a few
> statements. Good point.
If I'm not mistaken, it would be more of a move combined with
creating a new file. My impression was that the sequence worked
something like this:
1. Logrotate moves the old log file to a new name, equivalent to
something like this:
mv postgresql.log postgresql.log.1
In the mean time, PG keeps writing to the same file.
2. Logrotate sends a HUP (as configured in the logrotate conf) to the
postmaster process, which causes PG to close the old log file
(postgresql.log.1) and open a new one (postgresql.log).
If I understand correctly, you're saying that this process either
won't work or isn't portable. Is that correct?
BTW, my rational is that we use logrotate for most of our other logs,
so I would like to put PG in the same system. If what I suggested
above won't work, I'll just set up PG to write to something like
postgresql.log_20070101 and write a script to gzip and clean up old
logs.