Re: Issues with Quorum Commit

On Thu, Oct 7, 2010 at 2:31 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> 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?

Establishing an affinity between a session and one of the database
servers will only help if the traffic is strictly read-only.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company