Re: A single escape required for log_filename

Andrew,

* Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> Stephen Frost wrote:
>> Yes, logrotate will happily call external applications. Maybe I'm
>> missing something, but obviously if PG can't be configured with a fixed
>> filename, pg_rotate_logfile() doesn't help the situation.
>
> I should think a good rotator tool didn't need a fixed filename either.

Sure, you could hack up something to deal with the name changing
constantly, and also hack up a script to call pg_rotate_logfile() when
necessary, and move the file to the name you want, but all in all,
that's a terrible solution, rather fragile, and worse than just using
copytruncate.

> I'm not sure what postgres does if the filename contains %% as the only
> escape, although that's would be a fairly ugly hack.

Based on my read of logfile_getname and pg_strftime/_fmt, it would
produce a '%' in the filename, but not add a timestamp. That's good,
but still kind of awkward and counter-intuitive. I'd also be a bit
concerned that the "doesn't-add-timestamp" behavior might change, and
that if we made the default configuration use that behavior we'd have to
add a huge comment above it explaining all of this so that an end-user
doesn't remove it from logfile name and break things unintentionally.

Honestly, I feel it's terrible to blatently ignore what the
administrator asked for and to not provide any mechanism for the user to
get what they want. If an administrator isn't aware or doesn't
understand log rotation issues they're going to have alot larger
problems than the PostgreSQL log.

In terms of a solution, I realize we have some backwards-compatibility
issues to deal with, but in general I think we should allow the
administrator to pick whatever filename they want. We could add another
option of 'log_add_timestamp' and default to true, though I suspect some
will be unhappy with that approach. We could change it and mention it
very clearly in the release notes as an alternative. Using
pg_rotate_log() as a way to force a log re-opening is alright, but I'd
prefer we do it on SIGHUP regardless, that's an extremely common
approach and quite reasonably, imv.

Thanks,

Stephen