On Monday, February 18, 2013 8:28 PM Rafael Martinez wrote:
> On 02/18/2013 03:41 PM, Amit Kapila wrote:
> [...........]
> > Why you think this is wrong behavior, do you expect any time you
> > call pg_rotate_logfile(), it should truncate the file if
> > log_truncate_on_rotation is on? I think if you are expecting such
> > behavior, it might not be right expectation, because it considers
> > the the time and log_filename format as well.
> >
> 
> Hello
> 
> I agree with Sari in this report.
> 
> If you call pg_rotate_logfile() AND log_truncate_on_rotation is on,
> the logfile should be truncated. This should happen even if the
> logfile name does not change during rotation, and even if
> log_rotation_age / log_rotation_size are defined.
> 
> According to the documentation:
> 
> "log_truncate_on_rotation ... When logging_collector is enabled, this
> parameter will cause PostgreSQL to truncate (overwrite), rather than
> append to, any existing log file of the same name ..."

Further description for log_truncate_on_rotation is as follows:

However, truncation will occur only when a new file is being opened due to 
time-based rotation, not during server startup or size-based rotation.

For example, using this setting in combination with a log_filename like 
postgresql-%H.log would result in generating twenty-four hourly log files and 
then cyclically overwriting them. This parameter can only be set in the 
postgresql.conf file or on the server command line. 

Example: To keep 7 days of logs, one log file per day named server_log.Mon, 
server_log.Tue, etc, and automatically overwrite last week's log with this 
week's log, set log_filename to server_log.%a, log_truncate_on_rotation to on, 
and log_rotation_age to 1440.

In the examples, it is clearly shown that, truncation will not happen only on 
based of log_truncate_on_rotation.


> "... pg_rotate_logfile signals the log-file manager to switch to a new
> output file immediately"

By reading the description of pg_rotate_logfile, it can mean that this is 
function to achieve what you are saying.
But as per code, it is not so.

By the way, why you want this function to behave in such a way, that it can 
override the meaning of other log parameters?

With Regards,
Amit Kapila.



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to