On Wed, May 26, 2010 at 9:54 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, 2010-05-26 at 07:10 -0400, Robert Haas wrote:
>
>> OK. In words of one syllable, your way still has all the same knobs,
>> plus some more.
>
> I explained how the per-standby settings would take many parameters,
> whereas per-transaction settings take far fewer.
>
>> You sketched out a design which still had a per-standby setting for
>> each standby, but IN ADDITION had a setting for a setting to control
>> quorum commit[1].
>
> No, you misread it. Again. The parameters were not IN ADDITION -
> obviously so, otherwise I wouldn't claim there were fewer, would I?
Well, that does seem logical, but I can't figure out how to reconcile
that with what you wrote before, because as far as I can see you're
just saying over and over again that your way will need fewer
parameters without explaining which parameters your way won't need.
And frankly, I don't think it's possible for quorum commit to reduce
the number of parameters. Even if we have that feature available, not
everyone will want to use it. And the people who don't will
presumably need whatever parameters they would have needed if quorum
commit hadn't been available in the first place.
> Your reply has again avoided the subject of how we would handle failure
> modes with per-standby settings. That is important.
I don't think anyone is avoiding that, we just haven't discussed it.
The thing is, I don't think quorum commit actually does anything to
address that problem. If I have a master and a standby configured for
sync rep and the standby goes down, we have to decide what impact that
has on the master. If I have a master and two standbys configured for
sync rep with quorum commit such that I only need an ack from one of
them, and they both go down, we still have to decide what impact that
has on the master. I agree we need to talk about, but I don't agree
that putting in quorum commit will remove the need to design that
case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
