Re: Reopen logfile on SIGHUP
От | Grigory Smolkin |
---|---|
Тема | Re: Reopen logfile on SIGHUP |
Дата | |
Msg-id | 5a42269e-55c4-17ad-7f1d-8caa83b990f9@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Reopen logfile on SIGHUP (Greg Stark <stark@mit.edu>) |
Список | pgsql-hackers |
If there is already SIGUSR1 for logfile reopening then shouldn`t postmaster watch for it? Postmaster PID is easy to obtain. On 02/28/2018 01:32 AM, 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. > > 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. > -- Grigory Smolkin Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: