Re: log_collector doesn't respond to reloads

Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> writes:
> Might be a red herring, but I was able to reproduce this if (and only
> if) I forgot to create the new dest directory before doing the reload.
> Subsequently creating the directory and reloading did not result in a
> file in the new location.

Hmm, interesting point. There's this code in there when fopen'ing the
log file fails:

/*
* ENFILE/EMFILE are not too surprising on a busy system; just
* keep using the old file till we manage to get a new one.
* Otherwise, assume something's wrong with Log_directory and stop
* trying to create files.
*/
if (errno != ENFILE && errno != EMFILE)
{
ereport(LOG,
(errmsg("disabling automatic rotation (use SIGHUP to re-enable)")));
Log_RotationAge = 0;
Log_RotationSize = 0;
}

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?)

Another point here is that the syslogger will attempt to create the log
directory if it's not there ... but only once, during startup. Should
we have it repeat that after a SIGHUP?

regards, tom lane