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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
Date: 2013-02-19 11:12:51
Message-ID: 24570.1361272371@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2013-02-19 11:27:28 Re: Nested xmlagg doesn't give a result 9.2.3
Previous Message Rafael Martinez 2013-02-19 10:58:39 Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on