Hi, I made a patch for REL9_3_STABLE which gets rid of old promote processing. please check it. This patch make PostgreSQL do fast promoting(*) always. (*) which means skipping long checkpoint before increasing timeline.
And after this, I'll do make another patch for unlinking files which are created by user as a trigger_file or "pg_ctl promote" command. --------------- Tomonari Katsumata 2013/7/30 Fujii Masao <masao.fu...@gmail.com> > On Sat, Jul 27, 2013 at 6:57 PM, Tomonari Katsumata > <t.katsumata1...@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 >
Description: Binary data
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers