Re: [HACKERS] Quorum commit for multiple synchronous replication. - Mailing list pgsql-hackers

From Noah Misch
Subject Re: [HACKERS] Quorum commit for multiple synchronous replication.
Date
Msg-id 20170421063434.GC184144@rfd.leadboat.com
Whole thread Raw
In response to Re: [HACKERS] Quorum commit for multiple synchronous replication.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [HACKERS] Quorum commit for multiple synchronous replication.  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Fri, Apr 21, 2017 at 01:20:05PM +0900, Masahiko Sawada wrote:
> On Fri, Apr 21, 2017 at 12:02 PM, Noah Misch <noah@leadboat.com> wrote:
> > On Wed, Apr 19, 2017 at 01:52:53PM +0900, Masahiko Sawada wrote:
> >> On Wed, Apr 19, 2017 at 12:34 PM, Noah Misch <noah@leadboat.com> wrote:
> >> > On Sun, Apr 16, 2017 at 07:25:28PM +0900, Fujii Masao wrote:
> >> >> As I told firstly this is not a bug. There are some proposals for better design
> >> >> of priority column in pg_stat_replication, but we've not reached the consensus
> >> >> yet. So I think that it's better to move this open item to "Design Decisions to
> >> >> Recheck Mid-Beta" section so that we can hear more opinions.
> >> >
> >> > I'm reading that some people want to report NULL priority, some people want to
> >> > report a constant 1 priority, and nobody wants the current behavior.  Is that
> >> > an accurate summary?
> >>
> >> Yes, I think that's correct.
> >
> > Okay, but ...
> >
> >> FWIW the reason of current behavior is that it would be useful for the
> >> user who is willing to switch from ANY to FIRST. They can know which
> >> standbys will become sync or potential.
> >
> > ... does this mean you personally want to keep the current behavior?  If not,
> > has some other person stated a wish to keep the current behavior?
> 
> No, I want to change the current behavior. IMO it's better to set
> priority 1 to all standbys in quorum set. I guess there is no longer
> person who supports the current behavior.

In that case, this open item is not eligible for section "Design Decisions to
Recheck Mid-Beta".  That section is for items where we'll probably change
nothing, but we plan to recheck later just in case.  Here, we expect to change
the behavior; the open question is which replacement behavior to prefer.

Fujii, as the owner of this open item, you are responsible for moderating the
debate until there's adequate consensus to make a particular change or to keep
the current behavior after all.  Please proceed to do that.  Beta testers
deserve a UI they may like, not a UI you already plan to change later.

Thanks,
nm



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] AGG_HASHED cost estimate
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables