Re: Issues with Quorum Commit

Robert Haas  wrote:
> Kevin Grittner  wrote:
>> With web applications, at least, you often don't care that the
>> data read is absolutely up-to-date, as long as the point in time
>> doesn't jump around from one request to the next.  When we have
>> used load balancing between multiple database servers (which has
>> actually become unnecessary for us lately because PostgreSQL has
>> gotten so darned fast!), we have established affinity between a
>> session and one of the database servers, so that if they became
>> slightly out of sync, data would not pop in and out of existence
>> arbitrarily.  I think a reasonable person could combine this
>> technique with a "3 of 10" synchronous replication quorum to get
>> both safe persistence of data and reasonable performance.
>> 
>> I can also envision use cases where this would not be desirable.
> 
> Well, keep in mind all updates have to be done on the single
> master.  That works pretty well for fine-grained replication, but
> I don't think it's very good for full-cluster replication.
I'm completely failing to understand your point here.  Could you
restate another way?
-Kevin