Re: Reopen logfile on SIGHUP
От | Andres Freund |
---|---|
Тема | Re: Reopen logfile on SIGHUP |
Дата | |
Msg-id | 20180227224623.hqfx5gwx776ev5fd@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Reopen logfile on SIGHUP (Greg Stark <stark@mit.edu>) |
Ответы |
Re: Reopen logfile on SIGHUP
|
Список | pgsql-hackers |
On 2018-02-27 22:32:41 +0000, Greg Stark wrote: > On 27 February 2018 at 14:41, Anastasia Lubennikova > <a.lubennikova@postgrespro.ru> wrote: > > > Small patch in the attachment implements logfile reopeninig on SIGHUP. > > It only affects the file accessed by logging collector, which name you can > > check with pg_current_logfile(). > > HUP will cause Postgres to reload its config files. That seems like a > fine time to reopen the log files as well but it would be nice if > there was also some way to get it to *just* do that and not reload the > config files. Is that an actually important thing to be able to do? > I wonder if it would be easiest to just have the syslogger watch for > some other signal as well (I'm guessing the the syslogger doesn't use > relcache invalidations so it could reuse USR1 for example). That would > be a bit inconvenient as the admins would have to find the syslogger > and deliver the signal directly, rather than through the postmaster > but it would be pretty easy for them. -many. We have been "signal starved" a number of times, and definitely shouldn't waste one on this. - Andres
В списке pgsql-hackers по дате отправления: