From: | Tomonari Katsumata <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: comment for "fast promote" |
Date: | 2013-07-26 02:19:50 |
Message-ID: | 51F1DCC6.6000101@po.ntts.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp> wrote:
>> Hi,
>>
>> Now I'm seeing xlog.c in 93_stable for studying "fast promote",
>> and I 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 prevents PROMOTE_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 postmaster by hand. This seems messy.
>
> I think that we should remove normal promotion at all, or change
> pg_ctl promote so that 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
From | Date | Subject | |
---|---|---|---|
Next Message | amutu | 2013-07-26 02:23:10 | BUG #8335: trim() un-document behaviour |
Previous Message | Josh Berkus | 2013-07-26 00:52:37 | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |