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.
- Heikki