-----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----- -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
