Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
Date
Msg-id 24570.1361272371@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on  (Rafael Martinez <r.m.guerrero@usit.uio.no>)
Responses Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on  (Rafael Martinez <r.m.guerrero@usit.uio.no>)
List 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 by date:

Previous
From: Rafael Martinez
Date:
Subject: Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
Next
From: Michael Paquier
Date:
Subject: Re: Nested xmlagg doesn't give a result 9.2.3