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"  (Fujii Masao <masao.fujii@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: Expression indexes and dependecies