Attached is a very much VIP (AKA rough draft) for $subject.
Right now we have two parameters controlling logging destination, and they work in interesting combinations:
log_destination=stderr, logging_collector=off -> log to stderr (makes sense)
log_destination=stderr, logging_collector=on -> log to file (*highly* illogical for most users, to set stderr when they want file)
log_destination=csvlog, logging_collector=on -> log to csvfile (makes sense)
log_destination=csvlog, logging_collector=off -> fail (ugh)
(beyond that we also have syslog and eventlog, but those are different and not touched by this patch)
My understanding is that the main reason for this is that we cannot change logging_collector without restarting postmaster, whereas we can change log_destination.
My suggestion is we work around this by just always starting the logging collector, even if we're not planning to use it. Then we'd just have:
log_destination = stderr -> log to stderr
log_destination = file -> log to file
log_destination = csvlog -> log to csv file
The main difference here is that log_destination=stderr would also go through the logging collector which would then assemble it and write it out to it's own stderr.
Do people see an actual problem with that? I agree it's an extra round of indirection there, but is that a problem? It would also cause one more backgorund process to always be running, but again, is that really a problem? The overhead is not exactly large.
It would make configuration a lot more logical for logging. It would also make it possible to switch between all logging configurations without restarting.
The attached WIP is mostly working for the simple cases. It fails completely if the syslogger is restarted at this point, simply because I haven't figured out how to pass the original stderr down to the syslogger. I'm sure there are also many other smaller issues around it, but I wanted to get the discussion done before I spend the time to go through those.
Thoughts?
--
