Re: log_collector doesn't respond to reloads

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> 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.

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.

> Consider the case that time elapses before anyone discovers that logs
> are not being written to the new location,

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.

We clearly need to fix the "disable rotation" logic, and I think a
good case can be made for trying a mkdir() when Log_directory changes,
but I don't see that there's more that can be done about this kind
of situation.

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.

regards, tom lane