On Sat, Dec 13, 2008 at 1:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Robert Haas" <robertmh...@gmail.com> writes: >> I think we need to reserve the term "synchronous replication" for a >> system where transactions that begin at the same time on the primary >> and standby see the same tuples. Clearly that is "more" synchronous > > We won't call it anything, because we never will or can implement that. > See the theory of relativity: the notion of exactly simultaneous events
OK, fine. I'll be more precise. I think we need to reserve the term "synchronous replication" for a system where transactions that begin on the standby after the transactions has committed on the master see the effects of the committed transaction. > at distinct locations isn't even well-defined, because observers at yet > other locations will disagree about what is "simultaneous". And I'm > not just making a joke here --- speed-of-light delays in a WAN are > meaningful compared to current computer speeds. In practice, the > slave and the master will never commit at exactly the same time. > > I agree with the point made upthread that we should use the term > "synchronous replication" the way it's commonly used in the industry. > Inventing our own terminology might be fun but it's not really going > to result in less confusion. I just googled "synchronous replication" and read through the first page of hits. Most of them do not address the question of whether synchronous replication can be said to have be completed when WAL has been received by the standby not but yet applied. One of the ones that does is: http://code.google.com/p/google-mysql-tools/wiki/SemiSyncReplicationDesign ...which refers to what we're proposing to call "Synchronous Replication" as "Semi-Synchronous Replication" (or 2-safe replication) specifically to distinguish it. The other is: http://www.cnds.jhu.edu/pub/papers/cnds-2002-4.pdf ...which doesn't specifically examine the issue but seems to take the opposite position, namely that the server on which the transaction is executed needs to wait only for one server to apply the changes to the database (the others need only to know that they need to commit it; they don't actually need to have done it). However, that same paper refers to two-phase commit as a synchronous replication algorithm, and Wikipedia's discussion of two-phase commit: http://en.wikipedia.org/wiki/Two-phase_commit_protocol ...clearly implies that the transaction must be applied everywhere before it can be said to have committed. The second page of Google results is mostly a further discussion of the MySQL solution, which is mostly described as "semi-synchronous replication". Simon Riggs said upthread that Oracle called this "synchronous redo transport". That is obviously much closer to what we are doing than "synchronous replication". ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
