Re: Remove non-fast promotion Re: Should we remove a fallback promotion? take 2

At Wed, 22 Apr 2020 10:28:07 +0900, Ian Barwick <ian(dot)barwick(at)2ndquadrant(dot)com> wrote in
> On 2020/04/22 6:53, Alvaro Herrera wrote:
> > On 2020-Apr-21, Jehan-Guillaume de Rorthais wrote:
> >
> >> On Tue, 21 Apr 2020 15:36:22 +0900
> >> Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> >
> >>>> Also in that case, non-fast promotion is triggered. Since my patch
> >>>> tries to remove non-fast promotion, it's intentional to prevent them
> >>>> from doing that. But you think that we should not drop that because
> >>>> there are still some users for that?
> >>>
> >>> It would be good to ask around to folks maintaining HA solutions about
> >>> that change at least, as there could be a point in still letting
> >>> promotion to happen in this case, but switch silently to the fast
> >>> path.
> >>
> >> FWIW, PAF relies on pg_ctl promote. No need for non-fast promotion.
> > AFAICT repmgr uses 'pg_ctl promote', and has since version 3.0
> > (released
> > in mid 2015). It was only 3.3.2 (mid 2017) that supported Postgres
> > 10,
> > so it seems fairly safe to assume that the removal won't be a problem.
>
> Correct, repmgr uses "pg_ctl promote" or pg_promote() (if available),
> and
> won't be affected by this change.

For the record, the pgsql resource agent uses "pg_ctl promote" and
working with fast-promote. Auxiliary tools for it is assuming
fast-promote.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center