Re: Quorum commit for multiple synchronous replication.
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: sawada.mshk@gmail.com
Cc: michael.paquier@gmail.com, masao.fujii@gmail.com, amit.kapila16@gmail.com,
robertmhaas@gmail.com, petr@2ndquadrant.com, vik@2ndquadrant.fr,
simon@2ndquadrant.com, josh@agliodbs.com, pgsql-hackers@postgresql.org
Date: 2016-12-15T06:06:20Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Set the priorities of all quorum synchronous standbys to 1.
- 346199dcab4c 10.0 landed
-
Improve documentation and comment for quorum-based sync replication.
- a790ed9f69ef 10.0 landed