Re: A single escape required for log_filename
От | Robert Haas |
---|---|
Тема | Re: A single escape required for log_filename |
Дата | |
Msg-id | 603c8f070901131743g72b614cga5b98aa0e0750a00@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: A single escape required for log_filename (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: A single escape required for log_filename
|
Список | pgsql-hackers |
On Tue, Jan 13, 2009 at 4:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> I have perfectly good log rotation utility that exists on my OS. (yes I >> am aware of the possibility of losing a log entry when using logrotate). > > You might think you do, but it won't work with PG; external rotators > only work with programs that respond to SIGHUP by re-opening their log > files. If that were true, then we would surely want to change it so that it always re-opens the log file in response to SIGHUP. But I don't think it is - it seems we have pg_rotate_logfile() for that purpose. Standard utilities like the logrotate that ships with Fedora can run an external command after rotating the log file, and that external command can arrange to invoke pg_rotate_logfile(). Admittedly, this may be a little bit clunky: maybe we should always reopen the logfiles on receipt of a SIGHUP, since there doesn't seem to be much of a downside. (It's true that if we go that route more people will set up external log rotators to SIGHUP PostgreSQL, and that could increase the chance of SIGHUP causing the postgresql.conf file to be reloaded when the user wasn't quite ready, but that doesn't seem to be much of an argument for not doing it. Apache does the same thing, and on one occasion it took down my entire web server, but I don't blame the Apache project for the fact that I left my configuration in a screwed-up state before taking off for the weekend.) Automatically adding the date is a much bigger problem for an external rotator. It means that there is no way to get a constant filename. I don't think there's a clean way to handle that situation using Red Hat's logrotate, which may be why Red Hat's out-of-the-box PG configuration doesn't handle PG logfiles the way it handles all of its other log files, which may be why I wasn't really aware that PG even HAD a log file until about six months ago. Suggested patch attached. ...Robert
Вложения
В списке pgsql-hackers по дате отправления: