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