Re: comment for "fast promote"
От | Tomonari Katsumata |
---|---|
Тема | Re: comment for "fast promote" |
Дата | |
Msg-id | 51F1DCC6.6000101@po.ntts.co.jp обсуждение исходный текст |
Ответ на | Re: comment for "fast promote" (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: comment for "fast promote"
|
Список | pgsql-hackers |
Hi Fujii-san, Thank you for response. (2013/07/25 21:15), Fujii Masao wrote:> On Thu, Jul 25, 2013 at 5:33 PM, Tomonari Katsumata> <katsumata.tomonari@po.ntts.co.jp>wrote:>> Hi,>>>> Now I'm seeing xlog.c in 93_stable for studying "fast promote",>> andI have a question.>>>> I think it has an extra unlink command for "promote" file.>> (on 9937 line)>> ------->> 9934 if(stat(FAST_PROMOTE_SIGNAL_FILE, &stat_buf) == 0)>> 9935 {>> 9936 unlink(FAST_PROMOTE_SIGNAL_FILE);>> 9937 unlink(PROMOTE_SIGNAL_FILE);>>9938 fast_promote = true;>> 9939 }>> ------->>>> Is this command necesary ?>> Yes, it preventsPROMOTE_SIGNAL_FILE from remaining even if> both promote files exist.> The command("unlink(PROMOTE_SIGNAL_FILE)") here is for unusualy case. Because the case is when done both procedures below. - user create "promote" file on PGDATA - user issue "pg_ctl promote" I understand the reason. But I think it's better to unlink(PROMOTE_SIGNAL_FILE) before unlink(FAST_PROMOTE_SIGNAL_FILE). Because FAST_PROMOTE_SIGNAL_FILE is definetly there but PROMOTE_SIGNAL_FILE is sometimes there or not there. And I have another question linking this behavior. I think TriggerFile should be removed too. This is corner-case but it will happen. How do you think of it ? > One question is that: we really still need to support normal promote?> pg_ctl promote provides only way to do fast promotion.If we want to> do normal promotion, we need to create PROMOTE_SIGNAL_FILE> and send the SIGUSR1 signal to postmasterby hand. This seems messy.>> I think that we should remove normal promotion at all, or change> pg_ctl promote sothat provides also the way to do normal promotion.> I think he merit of "fast promote" is - allowing quick connection by skipping checkpoint and its demerit is - taking little bit longer when crash-recovery If it is seldom to happen its crash soon after promoting and "fast promte" never breaks consistency of database cluster, I think we don't need normal promotion. (of course we need to put detail about promotion on document.) regards, -------- NTT Software Corporation Tomonari Katsumata
В списке pgsql-hackers по дате отправления: