On 2020/11/05 12:12, Kyotaro Horiguchi wrote:
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.
Thanks for the review! I pushed the patch.
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?
I agree that we can use even standard SIGHUP handler in walreceiver.
I'm not sure why SetLatch() was not called in walreceiver's SIGHUP
handler so far.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
