> [] 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() 
can be 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 cleaning up.  Many other background 
children do so.

Takayuki Tsunakawa

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to