Re: Reopen logfile on SIGHUP - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Reopen logfile on SIGHUP
Date
Msg-id CAM-w4HPuvKe_UyfgfhooVMX=+EYGp=+okjy8_Fo2koBL0fggMg@mail.gmail.com
Whole thread Raw
In response to Reopen logfile on SIGHUP  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Responses Re: Reopen logfile on SIGHUP  (Andres Freund <andres@anarazel.de>)
Re: Reopen logfile on SIGHUP  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Reopen logfile on SIGHUP  (Grigory Smolkin <g.smolkin@postgrespro.ru>)
List pgsql-hackers
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.

-- 
greg


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly
Next
From: Peter Geoghegan
Date:
Subject: Re: pgsql: Avoid valgrind complaint about write() of uninitalized bytes.