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"
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
Are there any objection?
regards,
-------------------
Tomonari Katsumata
