Aidan Van Dyk <ai...@highrise.ca> wrote: > To get "non-stale" responses, you can only query those k=3 > servers. But you've shot your self in the foot because you don't > know which 3/10 those will be. The other 7 *are* stale (by > definition). They talk about picking the "caught up" slave when > the master fails, but you actually need to do that for *every > query*. 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. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
