From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Michael Paquier
> > By the way, doesn't this wait event belong to IPC wait event type, because
> the process is waiting for other conflicting processes to terminate the
> conflict conditions? Did you choose Timeout type because
> max_standby_{archive | streaming}_delay relates to this wait? I'm not
> confident which is appropriate, but I'm afraid users can associate this
> wait with a timeout.
>
> Actually I think that this event belongs to the timeout category, because
> we wait until the timeout has finished, the latch being here to be sure
> that the process is more responsive in case of a postmaster death.
OK. I confirmed the doc is fixed.
> > (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.
> > (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 without
cleaningup. Many other background children do so.
Regards
Takayuki Tsunakawa
