"Ed L." <[EMAIL PROTECTED]> writes: > One addition I'd like to include with the revised patch: a boolean > postgresql.conf option ('log_truncate_on_rotation', default false) to > truncate any existing log file by the same name. Default behavior here and > with Apache is to always append, but it's a useful feature for us because > it largely eliminates the issue of logs filling up the disk. You don't > want the log clobbered on restarts, so the idea is to only truncate during > time/size-based rotation, not on the initial open. Thoughts?
Hmm, so if you use e.g. "postgresql_%H.log", you always have 24 logfiles of one hour each, and you don't need any explicit code at all to remove old logs. Not a bad idea. It's definitely creeping featurism ... but I can see the value of not needing any cron daemon to remove old logs. A potential problem is what about size-driven rotation? If the hourly output exceeds log_rotation_size then you'd truncate and rewrite the current file, which is just exactly not what you want :-(. You could say that truncation occurs only at time-driven, not size-driven rotations, but that would effectively amount to saying that size-driven rotation is disabled, which I don't think I like ... One other thing I've been thinking of suggesting is that the next-rotation-target-time be rounded to an exact multiple of log_rotation_age. So for example if you set log_rotation_age = 60 minutes then rotations will happen at the top of the hour no matter when the postmaster was started. The simplistic approach of doing this on the time_t value would mean that, say, age = 24*60 would give you rotations occurring at GMT midnight not local midnight, which isn't perfect but I'd say good enough. Again though, the interaction with size-driven rotation might need more thought. Possibly you could fix the first issue if you did all this to the code and then used, say, log_filename "postgresql_%H:%M.log" with 60-minute rotation. You'd normally get only logfiles named after the top of the hour, but in an hour with unusually heavy log output you might get some additional files with intermediate %M values. Course that puts you back to needing a cron daemon to clean those up ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly