-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/19/2013 12:12 PM, Tom Lane wrote:
> 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
Tom, I think we are talking past each other here.
The point here is that if you need to run pg_rotate_logfile() manually
is because something has happened in your system and you have taken
the decision of running manually a log rotation that truncates the log
file.
Think about this usercase from real live:
log_filename= 'postgres_%m.log'
log_truncate_on_rotation = on
log_rotation_age = 0
log_rotation_size = 0
We run pg_rotate_logfile() from cron every first day of the month at
00:00:01. This will give us 12 files that contain the logdata for the
month defined in the file name and they will we recycled after one
year because of the truncate parameter.
Think now that because an error in an application, or because we have
activated full logs for a period of time for debug purpouses, the size
of the active log file has grown to a point where we have to take
accion to avoid other problems (diskspace, parsing time, etc).
We should be able to run pg_rotate_logfile() i.e. in the middle of the
month and get the active logfile truncated if we are using
log_truncate_on_rotation = on. Don't you think?
In the way pg_rotate_logfile() and log_truncate_on_rotation = on work
today, we have to stop postgres to truncate the log file if an
unexpected situation happens and this is not always possible in a
production system.
If we need to run pg_rotate_logfile() manually in the middle of the
month and we don't want to lose the data in the file that is going to
be truncated, we will have to take a manual copy of it before running
pg_rotate_logfile().
This is a real life administration problem that I have seen many times
in different systems. We want and need logdata and to pipe it to
/dev/null is not an option to us.
truncate_on_rotation for us outside the development world of postgres,
means that, the file will get truncated on rotation independently of
the filename schema used.
Thanks for your time.
regards,
- --
Rafael Martinez Guerrero
Center for Information Technology
University of Oslo, Norway
PGP Public Key: http://folk.uio.no/rafael/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEARECAAYFAlEjcLcACgkQBhuKQurGihRXAQCghoRbIbWVWqb7vhAXY1nDcLEQ
n1QAn0e3me49/jWclcQ8iLKn2uL0A/mM
=NShe
-----END PGP SIGNATURE-----