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

On Monday, February 18, 2013 5:42 PM sari thiele wrote:
> The following bug has been logged on the website:
>=20
> Bug reference:      7890
> Logged by:          Sari Thiele
> Email address:      sari.thiele@usit.uio.no
> PostgreSQL version: 9.1.8
> Operating system:   Red Hat Enterprise Linux Server release 6.3
> Description:
>=20
> Hi,
>=20
> I am trying to use the function pg_rotate_logfile() to force a =
truncate
> of
> the current log file by setting the parameter =
"log_truncate_on_rotation
> =3D
> on".
> But it looks like that this does not work, like I expected.
>=20
> System info:
> Red Hat Enterprise Linux Server release 6.3 (Santiago)
>=20
> select version();
>                                                   version
>=20
> =
-----------------------------------------------------------------------
> ---------------------------------------
>  PostgreSQL 9.1.8 on x86_64-unknown-linux-gnu, compiled by gcc (GCC)
> 4.4.6
> 20120305 (Red Hat 4.4.6-4), 64-bit
>=20
>=20
> Parameter set-up:
>=20
> log_filename =3D 'postgresql-%F_%H.log'
> logging_collector =3D on
> log_truncate_on_rotation =3D on
> log_rotation_age =3D 1h
> log_rotation_size =3D 0
>=20
> SELECT pg_rotate_logfile();
>=20
> After the function call, the file is still filled with the previous
> data.
> After my understanding the log file should be emptied (truncated).
>=20
> -----------
> To check if there is something wrong with my set-up, I did some other
> tests,
> too.
>=20
> 1.
> log_filename =3D 'postgresql-%F_%T.log'
> logging_collector =3D on
> log_truncate_on_rotation =3D on
> log_rotation_age =3D 1h
> log_rotation_size =3D 0
>=20
> SELECT pg_rotate_logfile();
>=20
> After the function call a new file is generated, because of the
> logfilename
> string (HH:MM:ss).
> This is correct.
>=20
> -------------------------
> 2.
> log_filename =3D 'postgresql-%M.log'
> logging_collector =3D on
> log_truncate_on_rotation =3D on
> log_rotation_age =3D 10min
> log_rotation_size =3D 0
>=20
> Here is the file automatically truncated after an hour, because of the
> file
> name. So that works also correct.
>=20
> ----
>=20
> We checked the source code and it looks like the problem could be =
here:
>=20
> src/backend/postmaster/syslogger.c
>=20
>=20
> /*
>  * Decide whether to overwrite or append.  We can overwrite if (a)
>  * Log_truncate_on_rotation is set, (b) the rotation was triggered by
>  * elapsed time and not something else, and (c) the computed file name
> is
>  * different from what we were previously logging into.
>  *
>  * Note: last_file_name should never be NULL here, but if it is,
> append.
>  */
>  if (time_based_rotation || (size_rotation_for
> &LOG_DESTINATION_STDERR))
>     {
>      if (Log_truncate_on_rotation && time_based_rotation &&
>          last_file_name !=3D NULL &&
>          strcmp(filename, last_file_name) !=3D 0) =3D=3D> *
>         fh =3D logfile_open(filename, "w", true);
>      else
>         fh =3D logfile_open(filename, "a", true);
>=20
>=20
> =3D=3D> * this checks if the new file name is different from the old =
one.
> In my case it is still the same name and so the new log lines will be
> appended to the current file, not truncated like I expected.
> I think this is the wrong behaviour, what do you think?

The only reason is you have used pg_rotate_logfile() to perform the =
action, otherwise if it would have been done
based on time, it should have truncated the file.
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.=20

With Regards,
Amit Kapila.