At Thu, 15 Dec 2016 14:20:53 +0900, Masahiko Sawada <sawada.m...@gmail.com> wrote in <cad21aodn73ac+o0mrwcs800leosmyp4ov7xvb0t0_4v5vcq...@mail.gmail.com> > On Thu, Dec 15, 2016 at 11:23 AM, Michael Paquier > <michael.paqu...@gmail.com> wrote: > > On Thu, Dec 15, 2016 at 11:04 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > >> On Thu, Dec 15, 2016 at 6:47 AM, Michael Paquier > >> <michael.paqu...@gmail.com> wrote: > >>> On Wed, Dec 14, 2016 at 11:34 PM, Fujii Masao <masao.fu...@gmail.com> > >>> wrote: > >>>> If we drop the "standby_list" syntax, I don't think that new parameter is > >>>> necessary. We can keep s_s_names and just drop the support for that > >>>> syntax > >>>> from s_s_names. This may be ok if we're really in "break all the things" > >>>> mode > >>>> for PostgreSQL 10. > >>> > >>> Please let's not raise that as an argument again... And not break the > >>> s_list argument. Many users depend on that for just single sync > >>> standbys. FWIW, I'd be in favor of backward compatibility and say that > >>> a standby list is a priority list if we can maintain that. Upthread > >>> agreement was to break that, I did not insist further, and won't if > >>> that's still the feeling. > >> > >> I wonder why you think that the backward-compatibility for standby_list is > >> so "special". We renamed pg_xlog directory to pg_wal and are planning to > >> change recovery.conf API at all, though they have bigger impacts on > >> the existing users in terms of the backward compatibility. OTOH, so far, > >> changing GUC between major releases happened several times. > > > > Silent failures for existing failover deployments is a pain to solve > > after doing upgrades. That's my only concern. Changing pg_wal would > > result in a hard failure when upgrading. And changing the meaning of > > the standby list (without keyword ANY or FIRST!) does not fall into > > that category... So yes just removing support for standby list would > > result in a hard failure, which would be fine for the > > let-s-break-all-things move. > > > >> But I'm not against keeping the backward compatibility for standby_list, > >> to be honest. My concern is that the latest patch tries to support > >> the backward compatibility "partially" and which would be confusing to > >> users, > >> as I told upthread. > > If we try to support backward compatibility, I'd personally do it > > fully, and have a list of standby names specified meaning a priority > > list. > > > >> So I'd like to propose to keep the backward compatibility fully for > >> s_s_names > >> (i.e., both "standby_list" and "N (standby_list)" mean the priority method) > >> at the first commit, then continue discussing this and change it if we > >> reach > >> the consensus until PostgreSQL 10 is actually released. Thought? > > > > +1 on that. > > +1.
FWIW, +1 from me. > I'll update the patch. -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers