Re: Archive recovery won't be completed on some situation.

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: masao(dot)fujii(at)gmail(dot)com, hlinnakangas(at)vmware(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Archive recovery won't be completed on some situation.
Date: 2014-03-20 14:38:39
Message-ID: 20140320143839.GR6899@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kyotaro HORIGUCHI escribió:
> Hi, I confirmed that 82233ce7ea4 surely did it.
>
> At Wed, 19 Mar 2014 09:35:16 -0300, Alvaro Herrera wrote
> > Fujii Masao escribió:
> > > On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas
> > > <hlinnakangas(at)vmware(dot)com> wrote:
> >
> > > >> 9.4 canceles backup mode even on immediate shutdown so the
> > > >> operation causes no problem, but 9.3 and before are doesn't.
> > > >
> > > > Hmm, I don't think we've changed that behavior in 9.4.
> > >
> > > ISTM 82233ce7ea42d6ba519aaec63008aff49da6c7af changed immdiate
> > > shutdown that way.
> >
> > Uh, interesting. I didn't see that secondary effect. I hope it's not
> > for ill?
>
> The crucial factor for the behavior change is that pmdie has
> become not to exit immediately for SIGQUIT. 'case SIGQUIT:' in
> pmdie() ended with "ExitPostmaster(0)" before the patch but now
> it ends with 'PostmasterStateMachine(); break;' so continues to
> run with pmState = PM_WAIT_BACKENDS, similar to SIGINT (fast
> shutdown).
>
> After all, pmState changes to PM_NO_CHILDREN via PM_WAIT_DEAD_END
> by SIGCHLDs from non-significant processes, then CancelBackup().

Judging from what was being said on the thread, it seems that running
CancelBackup() after an immediate shutdown is better than not doing it,
correct?

> Focusing on the point described above, the small patch below
> rewinds the behavior back to 9.3 and before but I don't know the
> appropriateness in regard to the intention of the patch.

I see. Obviously your patch would, in effect, revert 82233ce7ea
completely, which is not something we want. I think if we want to go
back to the previous behavior of not stopping the backup, some other
method should be used.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-03-20 14:40:43 Re: Risk Estimation WAS: Planner hints in Postgresql
Previous Message Robert Haas 2014-03-20 13:35:38 Re: Portability issues in shm_mq