Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module
Date
Msg-id eeda13ff-9ed4-747b-b47b-a7983e2fab40@oss.nttdata.com
Whole thread Raw
In response to Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers

On 2020/11/10 16:17, Kyotaro Horiguchi wrote:
> At Sat, 7 Nov 2020 19:31:21 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in
>> The main reason for having SetLatch() in
>> SignalHandlerForConfigReload() is to wake up the calling process if
>> waiting in WaitLatchOrSocket() or WaitLatch() and reload the new
>> config file and use the reloaded config variables. Maybe we should
>> give a thought on the scenarios in which the walreceiver process
>> waits, and what happens in case the latch is set when SIGHUP is
>> received.
> 
> The difference is whether the config file is processed at the next
> wakeup (by force-reply-request or SIGTERM) of walreceiver or
> immediately. If server-reload happened frequently, say, several times
> per second(?), we should consider to reduce the useless reloading, but
> actually that's not the case.

So, attached is the patch that makes walreceiver use both standard
SIGTERM and SIGHUP handlers. Currently I've not found any actual
issues by making walreceiver use standard SIGHUP handler, yet.

Regards,

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

Attachment

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: A problem about partitionwise join
Next
From: Paul Guo
Date:
Subject: Re: Multi Inserts in CREATE TABLE AS - revived patch