At Tue, 21 Apr 2020 15:48:02 +0900, Fujii Masao <masao.fu...@oss.nttdata.com> wrote in > > > On 2020/04/21 15:36, Michael Paquier wrote: > > On Tue, Apr 21, 2020 at 03:29:54PM +0900, Fujii Masao wrote: > >> Yeah, but that's not documented. So I don't think that we need to keep > >> the backward-compatibility for that. > >> > >> 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. > > *If* there are some HA solutions doing that, IMO that they should be > *changed > so that the documented official way to trigger promotion (i.e., pg_ctl > promote, > pg_promote or trigger_file) is used instead.
The difference between fast and non-fast promotions is far trivial than the difference between promotion happens or not. I think everyone cares about the new version actually promotes by the steps they have been doing, but few of them even notices the difference between the fast and non-fast. If those who are using non-fast promotion for a certain reason should notice the change of promotion behavior in release notes. This is similar to the change of the default waiting behvaior of pg_ctl at PG10. regards. -- Kyotaro Horiguchi NTT Open Source Software Center