Re: Synchronous replication - Mailing list pgsql-hackers

From Joshua Tolley
Subject Re: Synchronous replication
Date
Msg-id 4c4e544a.0d87970a.7a9b.ffff8e20@mx.google.com
Whole thread Raw
In response to Re: Synchronous replication  (Yeb Havinga <yebhavinga@gmail.com>)
Responses Re: Synchronous replication
Re: Synchronous replication
List pgsql-hackers
On Thu, Jul 22, 2010 at 10:37:12AM +0200, Yeb Havinga wrote:
> Fujii Masao wrote:
> Initially I also expected the quorum to behave like described by
> Aidan/option 2. Also, IMHO the name "quorom" is a bit short, like having
> "maximum" but not saying a max_something.
>
> quorum_min_sync_standbys
> quorum_max_sync_standbys

Perhaps I'm hijacking the wrong thread for this, but I wonder if the quorum
idea is really the best thing for us. I've been thinking about Oracle's way of
doing things[1]. In short, there are three different modes: availability,
performance, and protection. "Protection" appears to mean that at least one
standby has applied the log; "availability" means at least one standby has
received the log info (it doesn't specify whether that info has been fsynced
or applied, but presumably does not mean "applied", since it's distinct from
"protection" mode); "performance" means replication is asynchronous. I'm not
sure this method is perfect, but it might be simpler than the quorum behavior
that has been considered, and adequate for actual use cases.

[1]
http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/protection.htm#SBYDB02000
alternatively, http://is.gd/dLkq4

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: dynamically allocating chunks from shared memory
Next
From: Tom Lane
Date:
Subject: Re: SSL cipher and version