Re: Archive recovery won't be completed on some situation.
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Archive recovery won't be completed on some situation. |
Дата | |
Msg-id | 20140328.135252.160997134.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Archive recovery won't be completed on some situation. (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
Hello, > > 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? Agreed. I like that behavior:) It removes backup_label at immediate shutdown and (altough I didn't see by myself but as far as I saw PostmasterStateMachine) it would skip shutdown checkponit. > > 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. As I mentioned above, I don't want to rewind 9.4's behavior back to that of previous ones. What I hope to be realized for now is '-b'(provisional optname) of pg_resetxlog for at least versions which would fall into this problem. What do you think about this maybe 'New Feature' but has meaning practically only for older versions? Of course I agree with that 'you should erase the backup_label just after master has crashed' is the most clean and sane way to *avoid* the situation but the penalty seems a bit too large for the mistake. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: