Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, bharath(dot)rupireddyforpostgres(at)gmail(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module
Date: 2020-11-10 09:34:44
Message-ID: eeda13ff-9ed4-747b-b47b-a7983e2fab40@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/11/10 16:17, Kyotaro Horiguchi wrote:
> At Sat, 7 Nov 2020 19:31:21 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)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 Content-Type Size
v3-use-standard-SIGTERM-and-SIGHUP-handlers-in-walreceiver-process.patch text/plain 3.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Guo 2020-11-10 10:17:15 Re: Multi Inserts in CREATE TABLE AS - revived patch
Previous Message Richard Guo 2020-11-10 09:12:58 Re: A problem about partitionwise join