MARK CALLAGHAN <mdcal...@gmail.com> wrote: > Markus Wanner <mar...@bluegap.ch> wrote: >> Google invented the term "semi-syncronous" for something that's >> essentially the same that we have, now, I think. However, I full >> heartedly hate that term (based on the reasoning that there's no >> semi-pregnant, either). To be fair, what we're considering calling semi-synchronous is something which tries to stay in synchronous mode but switches out of it when necessary to meet availability targets. Your analogy doesn't match up at all well -- at least without getting really ugly. > We didn't invent the term, we just implemented something that > Heikki Tuuri briefly described, for example: > http://bugs.mysql.com/bug.php?id=7440 > > In the Google patch and official MySQL version, the sequence is: > 1) commit on master > 2) wait for slave to ack > 3) return to user > > After step 1 another user on the master can observe the commit and > the following is possible: > 1) commit on master > 2) other user observes that commit on master > 3) master blows up and a user observed a commit that never made it > to a slave > > I do not think this sequence should be possible in a sync > replication system. Then the only thing you would consider sync replication, as far as I can see, is two phase commit, which we already have. So your use case seems to be covered already, and we're trying to address other people's needs. The guarantee that some people are looking for is that a successful commit means that the data has been persisted on two separate servers. Others want to try for that, but are willing to compromise it for HA; in general I think they want to know when the guarantee is not there so they can take action to get back to a safer condition. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
