Re: [HACKERS] Quorum commit for multiple synchronous replication.

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: [HACKERS] Quorum commit for multiple synchronous replication.
Дата
Msg-id 20161215.150620.26218949.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] Quorum commit for multiple synchronous replication.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: [HACKERS] Quorum commit for multiple synchronous replication.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
At Thu, 15 Dec 2016 14:20:53 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in
<CAD21AoDn73aC+o0mrWCs800LeOsMYP4oV7xVb0T0_4V5VCQzhQ@mail.gmail.com>
> On Thu, Dec 15, 2016 at 11:23 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> > On Thu, Dec 15, 2016 at 11:04 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> >> On Thu, Dec 15, 2016 at 6:47 AM, Michael Paquier
> >> <michael.paquier@gmail.com> wrote:
> >>> On Wed, Dec 14, 2016 at 11:34 PM, Fujii Masao <masao.fujii@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





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Quorum commit for multiple synchronous replication.
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol