David Lowry <dlowry@bju.edu> writes: > The docs state that if there are no %-escapes in log_filename, then > it will add the epoch onto the end of the log filename. Is there any > way to turn off this behavior and just use the filename specified in > log_filename? I'd like have all the log data written to a file like > postgresql.log and let logrotate do the rotation. 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly

"Joshua D. Drake" <jd@commandprompt.com> writes: > Tom Lane <tgl@sss.pgh.pa.us> 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

David Lowry <dlowry@bju.edu> writes: > 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? Specifically, PG does not respond to SIGHUP in the way you are imagining above. The log-file-switch capability is either nonexistent (if no log collector process) or built in (if log collector is active) and there doesn't seem any value in driving the latter from outside PG. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org