Re: Should we remove "not fast" promotion at all?

On Tue, Aug 6, 2013 at 12:52 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>
>
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> schrieb:
>>On Tue, Aug 6, 2013 at 11:40 AM, Andres Freund <andres(at)2ndquadrant(dot)com>
>>wrote:
>>> Hi,
>>>
>>> On 2013-08-06 03:24:58 +0900, Fujii Masao wrote:
>>>> Hi all,
>>>>
>>>> We discussed the $SUBJECT in the following threads:
>>>>
>>http://www.postgresql.org/message-id/CA+TgmoZbR+WL8E7MF_KRp6fY4FD2pMr11TPiuyjMFX_Vtg1Wrw@mail.gmail.com
>>>>
>>http://www.postgresql.org/message-id/CAHGQGwEBUvgcx8X+Z0Hh+VdwYcJ8KCuRuLt1jSsxeLxPcX=0_w@mail.gmail.com
>>>>
>>>> Our consensus seems to remove "not fast" promotion at all
>>>> because there is no use case for that promotion.
>>>>
>>>> Attached patch removes "not fast" promotion. Barring any objections,
>>>> I will commit this patch.
>>>
>>> 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.
>
> I am fine with only supporting doing the promotion in the old fashioned way, but I wouldn't protest against an option either.
Yeah an additional option would be the way to go especially if new
promotion modes are supported in the future. Btw, what I like about
this patch is that it opens the door for easier support of additional
promotion modes. Could it be possible to use this advantage to support
both the fast and non-fast promotions now with a new fresh structure?

>>Or, instead of normal promotion, it might be better to use another
>>promotion
>>technique like shutdown + remove recovery.conf + restart for that
>>purpose?
>
> That's a very bad thing to do since it suppresses the timeline increase...
Agreed with Andres. This is unsafe as it avoids as well all the safety
checks at the end of archive recovery.
--
Michael