On Wed, May 26, 2010 at 9:54 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers