<div dir="ltr">Hi,<br /><br />>>> Yes, it prevents PROMOTE_SIGNAL_FILE from remaining even if<br
/>>>>both promote files exist.<br />>>><br />>> The command("unlink(PROMOTE_SIGNAL_FILE)") here
isfor<br /> >> unusualy case.<br />>> Because the case is when done both procedures below.<br />>> -
usercreate "promote" file on PGDATA<br />>> - user issue "pg_ctl promote"<br />>><br />>> I
understandthe reason.<br /> >> But I think it's better to unlink(PROMOTE_SIGNAL_FILE) before<br />>>
unlink(FAST_PROMOTE_SIGNAL_FILE).<br/>>> Because FAST_PROMOTE_SIGNAL_FILE is definetly there but<br />>>
PROMOTE_SIGNAL_FILEis sometimes there or not there.<br /> ><br />> I could not understand why that's better.
Couldyou elaborate that?<br />><br />I'm sorry for less explanation.<br /><br />I've thought that errno would be set
ENOENTand<br />this may lead something wrong.<br /> I checked this and I know it's not problem.<br /><br />sorry for
confusingyou.<br /><br /><br />>> And I have another question linking this behavior.<br />>> I think
TriggerFileshould be removed too.<br />>> This is corner-case but it will happen.<br /> >> How do you think
ofit ?<br />><br />> I don't have strong opinion about that. I've never heard the complaint<br />> about that
currentbehavior so far.<br />><br />For example, please imagine the cascading replication environment and<br />
usingold master as a standby without copying the timeline history file<br />to new standby.<br /><br />-------<br />1.
replicating3 servers(A,B,C)<br />A->B->C<br />("trigger_file = /tmp/trig" is set in recovery_recovery.conf on B
andC.)<br /><br />2. stop server A and promoting server B with "touch /tmp/trig;pg_ctl promote"<br />B->C<br
/>(/tmp/trigfile remains on server B)<br /><br />4. stop server B and promoting server C with "pg_ctl promote"<br />
C<br/><br />5. making server B connect for standby of server C<br />C->B<br />---------<br /><br />In step5 server B
willpromote as soon as it starts,<br />because "/tmp/trig" is stil there.<br /><br /><br />>>> One question is
that:we really still need to support normal promote?<br /> >>> pg_ctl promote provides only way to do fast
promotion.If we want to<br />>>> do normal promotion, we need to create PROMOTE_SIGNAL_FILE<br />>>>
andsend the SIGUSR1 signal to postmaster by hand. This seems messy.<br /> >>><br />>>> I think that
weshould remove normal promotion at all, or change<br />>>> pg_ctl promote so that provides also the way to do
normalpromotion.<br />>>><br />>> I think he merit of "fast promote" is<br /> >> - allowing quick
connectionby skipping checkpoint<br />>> and its demerit is<br />>> - taking little bit longer when
crash-recovery<br/>>><br />>> If it is seldom to happen its crash soon after promoting<br /> >> and
"fastpromte" never breaks consistency of database cluster,<br />>> I think we don't need normal promotion.<br
/>><br/>> You can execute checkpoint after fast promotion for that.<br />><br /> OK.<br />Then I think we
shoulddo below things.<br />- removing normal promotion at all from source<br />- adding the know-how you suggest on
document<br/><br />Are there any objection?<br /><br />regards,<br />-------------------<br />Tomonari Katsumata<br
/><br/></div>