Re: log_collector doesn't respond to reloads
От | Tom Lane |
---|---|
Тема | Re: log_collector doesn't respond to reloads |
Дата | |
Msg-id | 20084.1335491774@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: log_collector doesn't respond to reloads (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>) |
Ответы |
Re: log_collector doesn't respond to reloads
Re: log_collector doesn't respond to reloads |
Список | pgsql-bugs |
Mark Kirkwood <mark.kirkwood@catalyst.net.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
В списке pgsql-bugs по дате отправления: