On Tue, Oct 5, 2010 at 10:33 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, 2010-10-05 at 09:07 -0500, Kevin Grittner wrote:
>> Simon Riggs <simon@2ndQuadrant.com> wrote:
>> > Robert Haas wrote:
>> >> Simon Riggs <simon@2ndquadrant.com> wrote:
>> >>> Josh Berkus wrote:
>> >>>>>>> Quorum commit, even with configurable vote weights, can't
>> >>>>>>> handle a requirement that a particular commit be replicated
>> >>>>>>> to (A || B) && (C || D).
>> >>>>>> Good point.
>> >>>
>> >>> Asking for quorum_commit = 3 would cover that requirement.
>> >>>
>> >>> Not exactly as requested,
>>
>> >> That's just not the same thing.
>> >
>> > In what important ways does it differ?
>>
>> When you have one server functioning at each site you'll block until
>> you get a third machine back, rather than replicating to both sites
>> and remaining functional.
>
> And that is so important a consideration that you would like to move
> from one parameter in one file to a whole set of parameters, set
> differently in 5 separate files?
I don't accept that this is the trade-off being proposed. You seem
convinced that having the config all in one place on the master is
going to make things much more complicated, but I can't see why.
> Is it a common use case that people
> have more than 3 separate servers for one application, which is where
> the difference shows itself.
Much of the engineering we are doing centers around use cases that are
considerably more complex than what most people will do in real life.
> Another check: does specifying replication by server in such detail mean
> we can't specify robustness at the transaction level? If we gave up that
> feature, it would be a great loss for performance tuning.
No, I don't think it means that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company