> 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
