Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
Дата
Msg-id 24570.1361272371@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on  (Rafael Martinez <r.m.guerrero@usit.uio.no>)
Ответы Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on  (Rafael Martinez <r.m.guerrero@usit.uio.no>)
Список pgsql-bugs
Rafael Martinez <r.m.guerrero@usit.uio.no> writes:
> Well, postgreSQL is versatile enough to allow you to decide many
> aspects of log rotation. It should be the user who decide what will
> happen with log data after and during a rotation.

TBH, I don't think the rotation configuration options need to cater for
stupid choices, and what you're describing sounds like a stupid choice.
Why wouldn't you configure, say, a finite set of daily- or hourly-named
files?  Even just ping-ponging between two log files would be enough to
prevent the scenario where you lose the freshest log entries.

If you don't care about keeping even the latest entries, then you don't
need a log at all, much less rotation --- just pipe it to /dev/null.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Rafael Martinez
Дата:
Сообщение: Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Nested xmlagg doesn't give a result 9.2.3