On Tue, Aug 6, 2013 at 8:05 PM, Tomonari Katsumata <t.katsumata1...@gmail.com> wrote: > Hi, > > 2013/8/6 Tom Lane <t...@sss.pgh.pa.us> >> >> Fujii Masao <masao.fu...@gmail.com> writes: >> > On Tue, Aug 6, 2013 at 11:40 AM, Andres Freund <and...@2ndquadrant.com> >> > wrote: >> >> FWIW I'd rather keep plain promotion for a release or two. TBH, I have >> >> a >> >> bit of trust issues regarding the new method, and I'd like to be able >> >> to >> >> test potential issues against a stock postgres by doing a normal >> >> instead >> >> of a fast promotion. >> >> > So we should add new option specifying the promotion mode, into pg_ctl? >> > Currently pg_ctl cannot trigger the normal promotion. >> >> It would be silly to add such an option if we want to remove the old mode >> in a release or two. >> >> I think what Andres is suggesting is to leave it as-is for 9.4 and then >> remove the old code in 9.5 or 9.6. Which seems prudent to me. >> > How about giving trigger_file an ability to chose "fast promote" and "normal > promote" > like the triggerfile of pg_standby. > It means that if the contents of the trigger_file is empty or 'smart' then > do "normal promote", > and it's 'fast' then do "fast promote". > I think this change would be smaller than change to pg_ctl. > And this would allow us to treat ${PGDATA}/promote and trigger_file only. > (because ${PGDATA}/fast_promote is not created automatically) Indeed, this would be the way to go to have an extensible format for other promotion modes or other actions that could be triggered by a standby. So why not taking the approach suggested by Katsumata-san now? One single file to rule them all, in this case called promote, including a keyword indicating the promotion action to take. This could be controlled by pg_ctl entirely, and opens the door to extra possible modes. -- Michael
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers