Re: Allow interrupts on waiting standby

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: 'Michael Paquier' <michael(dot)paquier(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "Andres Freund" <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow interrupts on waiting standby
Date: 2017-03-30 04:52:05
Message-ID: 0A3221C70F24FB45833433255569204D1F6BD8D3@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)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() 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.

Regards
Takayuki Tsunakawa

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Venkata B Nagothi 2017-03-30 04:59:14 Re: [HACKERS] Bug in Physical Replication Slots (at least 9.5)?
Previous Message Kyotaro HORIGUCHI 2017-03-30 04:51:56 Re: [HACKERS] Bug in Physical Replication Slots (at least 9.5)?