Re: log_filename_prefix --> log_filename + strftime()

"Ed L." <pgsql(at)bluepolka(dot)net> 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