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

From Kyotaro HORIGUCHI
Subject Re: Reopen logfile on SIGHUP
Date
Msg-id 20180821.092654.08014297.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Reopen logfile on SIGHUP  (Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>)
Responses Re: Reopen logfile on SIGHUP
Re: Reopen logfile on SIGHUP
List pgsql-hackers
At Fri, 10 Aug 2018 15:33:26 +0300, Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru> wrote in
<5142559a-82e6-b3e4-d6ed-8fd2d240c77e@postgrespro.ru>
> On 08/09/2018 10:33 AM, Kyotaro HORIGUCHI wrote:
> >
> > - Since I'm not sure unlink is signal-handler safe on all
> >    supported platforms, I moved unlink() call out of
> >    checkLogrotateSignal() to SysLoggerMain, just before rotating
> >    log file.
> 
> Which platforms specifically do you have in mind? unlink() is required
> to be async-signal-safe by POSIX.1-2001, which is required by UNIX 03,
> and these are rather old.

I suspect that something bad can happen on Windows. Another
reason for the movement I didn't mention was it is not necesarry
to be there. So I applied the principle that a signal handler
should be as small and simple as possible.  As the result the
flow of logrotate signal handling becomes similar to that for
promote signal.

> For UNIX 03-certified distributions, see this list:
> http://www.opengroup.org/csq/search/t=XY1.html
> For FreeBSD, unlink() was signal-safe at least in 4.0, which was
> released in 2000
>
https://www.freebsd.org/cgi/man.cgi?query=sigaction&apropos=0&sektion=0&manpath=FreeBSD+4.0-RELEASE&arch=default&format=html
> Debian 4.0, which was released in 2007 and had a 2.6 kernel, also
> claims to have a signal-safe unlink():
> https://www.freebsd.org/cgi/man.cgi?query=signal&apropos=0&sektion=0&manpath=Debian+4.0.9&arch=default&format=html

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Temporary tables prevent autovacuum, leading to XID wraparound
Next
From: Michael Paquier
Date:
Subject: Re: Improve behavior of concurrent ANALYZE/VACUUM