At Wed, 4 Nov 2020 21:16:29 +0530, Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote in > On Wed, Nov 4, 2020 at 2:36 PM Fujii Masao <masao.fu...@oss.nttdata.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
