Re: Should we remove "not fast" promotion at all? - Mailing list pgsql-hackers

On Thu, Aug 8, 2013 at 12:24 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-08-08 06:40:00 +0900, Michael Paquier wrote:
>> 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.
>
> Why are we suddenly trying to make this even more complicated? It's too
> late to redesign stuff without very good evidence that it's
> needed. Renaming trigger files and changing their format certainly
> doesn't seem appropriate post-beta.
>
> Let's just leave this as is, and remove the code in 9.4/9.5.
Sorry. I should have been clearer. I meant that for 9.4~ only. For 9.3
yes it's too late.
-- 
Michael