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.
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
