Re: Archive recovery won't be completed on some situation. - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Archive recovery won't be completed on some situation.
Date
Msg-id CAHGQGwG+DhN4P10XBG+Gra1Nm5wBEKQ4=xQa3L3=1cEZsYFtRQ@mail.gmail.com
Whole thread Raw
In response to Re: Archive recovery won't be completed on some situation.  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Archive recovery won't be completed on some situation.  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Mon, May 12, 2014 at 4:52 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> On 05/09/2014 05:19 PM, Fujii Masao wrote:
>>
>> On Thu, Mar 20, 2014 at 11:38 PM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>>>
>>> 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@vmware.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?
>>
>>
>> This is listed as a 9.4 Open Item, but no one seems to want to revert
>> this change.
>> So I'll drop this from the Open Item list barring objections.
>
>
> I object. We used to call CancelBackup() on immediate shutdown, which was
> good. That was inadvertently changed by commit 82233ce. That's a regression
> we should fix. I agree with Alvaro upthread that we don't want to revert
> 82233ce, but we should come up with a fix.

Hmm.. probably I have the same opinion with you. If I understand this correctly,
an immediate shutdown doesn't call CancelBackup() in 9.4 or before. But the
commit 82233ce unintentionally changed an immediate shutdown so that it calls
CancelBackup(). For now, no one wants to revert the current behavior. So I think
there is nothing that we have to do now. No?

Regards,

--
Fujii Masao



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_class.relpages/allvisible probably shouldn't be a int4
Next
From: Emre Hasegeli
Date:
Subject: Re: wrapping in extended mode doesn't work well with default pager