> Whoever wrote that thought that Log_RotationAge/Log_RotationSize would
> get reset to normal values during SIGHUP, but it's far from clear to me
> that any such thing would actually happen. However, this would only
> apply to Josh's problem if he was trying to set a bogus new value of
> log_directory, eg not there or not writable by postgres. In any case,
> if this is the locus of the problem, there ought to be instances of that
> log message in the active log file. (Josh?)
Aha.
Yeah, the problem is, directory permissions to the contrary, something
is preventing the logger from writing to that directory even though I
can do so as the logged-in postgres user. I'll bet it's their SAN
dynamic mounter thing, given the trouble it's been before. *sigh*.
So this is an issue peculiar to their system, and not a general case.
Sorry for the noise. I've seen transitory behavior like this before and
had hoped that I'd found a reproduceable test case. But no.
We do have one piece of unituitive behavior here though, which forms a
bit of a catch-22:
1. DBA changes the log directory
2. Log directory is unwriteable
3. Postgres continues writing to the old log_directory
4. SHOW log_directory displays the *new* log_directory
I think (4) here needs to change. We shouldn't be showing a different
log directory in pg_settings than we're actually writing to, ever.
Now, here's the Catch-22:
Consider the case that time elapses before anyone discovers that logs
are not being written to the new location, and you change personnel; how
would the new DBA have any idea where the old log was so that he could
read the log message about the unwriteable directory?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com