On Thu, Mar 30, 2017 at 1:52 PM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> From: pgsql-hackers-owner@postgresql.org
>> > (2) standby.c
>> > Do we need to specify WL_LATCH_SET? Who can set the latch? Do the
>> backends who ended the conflict set the latch?
>>
>> This makes the process able to react on SIGHUP. That's useful for
>> responsiveness.
>
> Oh, I see. But how does the startup process respond quickly? It seems that you need to call
HandleStartupProcInterrupts()instead of CHECK_FOR_INTERRUPTS(). But I'm not sure whether HandleStartupProcInterrupts()
canbe called here.
Bah. Of course you are right. We don't care about SetLatch() here as
signals are processed with a different code path than normal backends.
>> > (3) standby.c
>> > + if (rc & WL_LATCH_SET)
>> > + ResetLatch(MyLatch);
>> > +
>> > + /* emergency bailout if postmaster has died */
>> > + if (rc & WL_POSTMASTER_DEATH)
>> > + proc_exit(1);
>> >
>> > I thought the child processes have to terminate as soon as postmaster
>> vanishes. So, it would be better for the order of the two if statements
>> above to be reversed. proc_exit() could be exit(), as some children do
>> in postmaster/*.c.
>>
>> OK, reversed this order.
>
> I think exit() instead of proc_exit() better represents what the code wants to do -- terminate the process ASAP
withoutcleaning up. Many other background children do so.
Hm... OK.
--
Michael
