Tom,
> I thought about trying to leave similar breadcrumbs if the logging
> parameters are changed while the postmaster is running, but it would add a
> fair amount of complication to the patch, and I'm not sure there's a lot
> of value in it. On-the-fly logging parameter changes don't happen without
> active DBA involvement, so it's a lot harder to credit thaat somebody would
> not be expecting the data to start going somewhere else.
Well, I think doing that ALSO would be worthwhile for the TODO list.
I've often wished, for example, that if we switch log_directory the
*last* message in the old log file be "reloading postgresql with new
configuration" or something similar, so that I would know to look for a
new log file somewhere else. If you are, for example, logging only
errors, you wouldn't necessarily realize that logging on the file you're
tailing/monitoring has stopped.
The "active DBA involvement" argument doesn't hold much water given the
many avenues for someone to accidentally introduce a configuration
change they didn't intend.
However, I also realize that the complexity of this feature's
implementation would likely eclipse its usefulness. As such, I'd like
to put it on the TODO list for some future occasion when we need to mess
with log-switching code *anyway* and can include this.
>
> Thoughts? In particular, anyone want to bikeshed on the message wording?
>
> Does this rise to the level of a usability bug that ought to be
> back-patched? As I said, we've seen this type of thinko multiple
> times before.
Hmmm. On the one hand, I can't see the harm in it. On the other hand,
I'm reluctant to introduce non-critical behavior changes into
backbranches no matter how minor. What if we just put this in 9.3 and up?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
