Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module

At Wed, 4 Nov 2020 21:16:29 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> On Wed, Nov 4, 2020 at 2:36 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
> >
> > Regarding other two patches, I think that it's better to use MyLatch
> > rather than MyProc->procLatch or walrcv->latch in WaitLatch() and
> > ResetLatch(), like other code does. Attached are the updated versions
> > of the patches. Thought?
> >
>
> +1 for replacing MyProc->procLatch with MyLatch in the autoprewarm
> module, and the patch looks good to me.

Looks good to me, too.

> I'm not quite sure to replace all the places in the walreceiver
> process, for instance in WalRcvForceReply() we are using spinlock to
> acquire the latch pointer and . Others may have better thoughts on
> this.

The SIGTERM part looks good. The only difference between
WalRcvSigHupHandler and SignalHandlerForConfigReload is whether latch
is set or not. I don't think it's a problem that config-reload causes
an extra wakeup. Couldn't we do the same thing for SIGHUP?

We might even be able to reload config file in
ProcessWalRcvInterrupts().

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center