On Tue, Aug 6, 2013 at 8:05 PM, Tomonari Katsumata
<t.katsumata1122@gmail.com> wrote:
> Hi,
>
> 2013/8/6 Tom Lane <tgl@sss.pgh.pa.us>
>>
>> Fujii Masao <masao.fujii@gmail.com> writes:
>> > On Tue, Aug 6, 2013 at 11:40 AM, Andres Freund <andres@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
