Josh Berkus <josh@agliodbs.com> writes:
> 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.
In principle I see the risk, but I don't think I've ever seen an actual
report of someone getting confused this way by an on-the-fly logging
parameter change. Whereas there are numerous examples in the archives
of people not realizing that "pg_ctl -l foo" doesn't necessarily mean
that all the useful log output is in file foo. (Usually it's because
they're using a logging setup chosen by some packager, not by themselves.)
So I'm feeling that what you're suggesting is solving a different and
far less pressing problem than what I'm on about.
I did think a little bit about how to do it. For parameters that affect
where the logging collector writes data (probably only log_directory is
worth special handling), it would be quite easy to make the got_SIGHUP
code segment in syslogger.c emit a log message just before switching the
active value. However, if you want something similar for log_destination,
syslog_facility, syslog_ident, or event_source, it's far more problematic
because those settings affect the behavior of individual processes, and
so there's no unique point where we're switching from one log target to
another. We could have the postmaster report a value change but it's
likely that that message would not appear very close to the end of the
messages directed to the old target.
Another point here is that if you're tailing the current log file,
a plain old rotation (no parameter change anywhere) would also cut
you off without obvious notice. Maybe we shouldn't think about this
as a "change of parameter" problem, but just say it's worth emitting
an "end of log file" message anytime we're about to change to a new log
file, no matter the reason. But again, that's specific to the logging
collector case and doesn't help with any other log target. I also note
that I'm not familiar with any system logging tool that emits such
messages.
regards, tom lane
