> Well, sorry, but you can't have that. SHOW will tell you what your own
> backend thinks the value of the GUC variable is, but there is no way to
> know what's happening inside the logging collector process. And I'd be
> against trying to add a signaling mechanism that would support telling
> you that, because it would add fragility to the logging collector, which
> we don't want.
Hmmm. There's really no feasible way to determine where the actual
logging collector is logging to?
> I don't buy that argument. If things are working as intended, the
> collector ought to create a new file in the commanded location
> immediately. I would think any normal DBA would look for that, just
> to check that the SIGHUP had worked.
You're assuming that the change is happening attended. Consider
automated changes being deployed via puppet or chef, possibly across
many servers.
You can end up in a situation where the logs aren't going where they're
supposed to due to some external problem, and that the DBA has no way to
find out what went wrong because he doesn't know where the logs are *now*.
Mind you, I don't have a solution to suggest, but I think it's a real
problem.
And fixing the rotation bug will help that a lot; it would narrow down
the problem to the current day/hour, which would make it much more
likely that someone would know that the log location had changed.
> BTW, what log messages were you getting exactly? I'd have expected
> something about "could not open log file" as well as the "disabling
> automatic rotation" one.
2012-04-26 16:38:21 PDT [10180]: [2-1] user=,db= LOG: received SIGHUP,
reloading configuration files
2012-04-26 16:38:21 PDT [10181]: [1-1] user=,db= LOG: could not open
log file "/pglogs/check/logs/datacollection-2012-04-26-16-38": No such
file or directory
2012-04-26 16:38:21 PDT [10181]: [2-1] user=,db= LOG: disabling
automatic rotation (use SIGHUP to re-enable)
So, yes, exactly.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
