From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | michael(at)paquier(dot)xyz |
Cc: | amit(dot)kapila16(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, hlinnaka(at)iki(dot)fi, dilipbalaut(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Problem while setting the fpw with SIGHUP |
Date: | 2018-09-18 02:38:50 |
Message-ID: | 20180918.113850.164570138.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Thu, 6 Sep 2018 16:37:28 -0700, Michael Paquier <michael(at)paquier(dot)xyz> wrote in <20180906233728(dot)GR2726(at)paquier(dot)xyz>
> On Tue, Aug 28, 2018 at 07:34:36PM +0900, Kyotaro HORIGUCHI wrote:
> > Thanks for prompting. The difference is in a comment and I'm fine
> > with the change.
>
> /*
> * Properly accept or ignore signals the postmaster might send us.
> */
> - pqsignal(SIGHUP, StartupProcSigHupHandler); /* reload config file */
> + pqsignal(SIGHUP, SIG_IGN); /* ignore reload config */
>
> I am finally coming back to this patch set, and that's one of the first
> things I am going to help moving on for this CF. And this bit from the
> last patch series is not acceptable as there are some parameters which
> are used by the startup process which can be reloaded. One of them is
> wal_retrieve_retry_interval for tuning when fetching WAL at recovery.
The third patch actually is not mandatory in the patch set. The
only motive of that is it doesn't nothing. The handler for SIGHUP
just sets got_SIGHUP then wakes up the process, and the variable
is not looked up by no one. If you mind the change, it can be
removed with no side effect.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-09-18 02:42:27 | Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi |
Previous Message | Kyotaro HORIGUCHI | 2018-09-18 02:20:03 | Re: Changing the setting of wal_sender_timeout per standby |