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

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.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services