Re: comment for "fast promote" - Mailing list pgsql-hackers

On Sat, Jul 27, 2013 at 6:57 PM, Tomonari Katsumata
<t.katsumata1122@gmail.com> wrote:
> Hi,
>
>
>>>> 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.
>>
>> I could not understand why that's better. Could you elaborate that?
>>
> I'm sorry for less explanation.
>
> I've thought that errno would be set ENOENT and
> this may lead something wrong.
> I checked this and I know it's not problem.
>
> sorry for confusing you.
>
>
>
>>> 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 ?
>>
>> I don't have strong opinion about that. I've never heard the complaint
>> about that current behavior so far.
>>
> For example, please imagine the cascading replication environment and
> using old master as a standby without copying the timeline history file
> to new standby.
>
> -------
> 1. replicating 3 servers(A,B,C)
> A->B->C
> ("trigger_file = /tmp/trig" is set in recovery_recovery.conf on B and C.)
>
> 2. stop server A and promoting server B with "touch /tmp/trig;pg_ctl
> promote"

Why do you need to both create the trigger file and run pg_ctl promote?

Anyway, if the patch is useful for fail-safe and it doesn't break the current
behavior, I'd be happy to apply it. You are suggesting that we should remove
the trigger file in CheckForStandbyTrigger() even if pg_ctl promote is executed.
But there can be some cases where we can get out of the WAL replay loop,
for example, reach the recovery_target_xxx. So ISTM we should try to remove
both the trigger file and "promote" file at the end of recovery
instead. Thought?

> B->C
> (/tmp/trig file remains on server B)
>
> 4. stop server B and promoting server C with "pg_ctl promote"
> C
>
> 5. making server B connect for standby of server C
> C->B
> ---------
>
> In step5 server B will promote as soon as it starts,
> because "/tmp/trig" is stil there.
>
>
>
>>>> 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.
>>
>> You can execute checkpoint after fast promotion for that.
>>
> OK.
> Then I think we should do below things.
> - removing normal promotion at all from source
> - adding the know-how you suggest on document

IMO either is necessary.

Regards,

--
Fujii Masao