Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
References: 
 <CALj2ACXPorUqePswDtOeM_s82v9RW32E1fYmOPZ5NuE+TWKj_A@mail.gmail.com>
 <13156732-5189-af54-3d28-e2ee2a8568e0@oss.nttdata.com>
 <CALj2ACV9NrMDT5Ndpm5STUYRBfKQJoPOgA5a27a1XRc4h8wVYw@mail.gmail.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
Message-ID: <069fb3bc-3907-4d85-19fd-e4b2d2f004b4@oss.nttdata.com>
Date: Tue, 6 Oct 2020 14:50:50 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: 
 <CALj2ACV9NrMDT5Ndpm5STUYRBfKQJoPOgA5a27a1XRc4h8wVYw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2020/10/06 1:18, Bharath Rupireddy wrote:
> On Mon, Oct 5, 2020 at 8:04 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>
>> On 2020/10/05 19:45, Bharath Rupireddy wrote:
>>> Hi,
>>>
>>> Autoprewarm module is using it's own SIGHUP(apw_sigterm_handler, got_sigterm) and SIGTERM(apw_sighup_handler, got_sighup) handlers which are similar to standard signal handlers(except for a difference [1]). Isn't it good to remove them and  use standard SignalHandlerForConfigReload and SignalHandlerForShutdownRequest?
>>>
>>> Attaching the patch for the above changes.
>>>
>>> Looks like the commit[2] replaced custom handlers with standard handlers.
>>>
>>> Thoughts?
>>
>> +1
>>
>> The patch looks good to me.
>>
> 
> Thanks.
> 
>>
>> ISTM that we can also replace StartupProcSigHupHandler() in startup.c
>> with SignalHandlerForConfigReload() by making the startup process use
>> the general shared latch instead of its own one. POC patch attached.
>> Thought?
>>
> 
> I'm not quite sure whether it breaks something or not. I see that
> WakeupRecovery() with XLogCtl->recoveryWakeupLatch latch from the
> startup process is also being used in the walreceiver process. I may
> be wrong, but have some concern if the behaviour is different in case
> of EXEC_BACKEND and Windows?

Unless I'm wrong, regarding MyLatch, the behavior is not different
whether in EXEC_BACKEND or not. In both cases, SwitchToSharedLatch()
is called and MyLatch is set to the shared latch, i.e., MyProc->procLatch.


> 
> Another concern is that we are always using
> XLogCtl->recoveryWakeupLatch in shared mode, this makes sense as this
> latch is also being used in walrecevier. But sometimes, MyLatch is
> created in non-shared mode as well(see InitLatch(MyLatch)).

Yes, and then the startup process calls SwitchToSharedLatch() and
repoint MyLatch to the shared one.

> 
> Others may have better thoughts though.

Okay, I will reconsider the patch and post it separately later if necessary.


> 
>>
>> Probably we can also replace sigHupHandler() in syslogger.c with
>> SignalHandlerForConfigReload()? This would be separate patch, though.
>>
> 
> +1 to replace sigHupHandler() with SignalHandlerForConfigReload() as
> the latch and the functionality are pretty much the same.
> 
> WalReceiverMai(): I think we can also replace WalRcvShutdownHandler()
> with SignalHandlerForShutdownRequest() because walrcv->latch point to
> &MyProc->procLatch which in turn point to MyLatch.
> 
> Thoughts? If okay, we can combine these into a single patch. I will
> post an updated patch soon.

+1 Or it's also ok to make each patch separately.
Anyway, thanks!

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION