Re: Sync Rep: First Thoughts on Code - Mailing list pgsql-hackers

Robert Haas wrote: <blockquote cite="mid:603c8f070812131835v7839b68fj736c853241cc7813@mail.gmail.com" type="cite"><pre
wrap="">OnSat, Dec 13, 2008 at 1:29 PM, Tom Lane <a class="moz-txt-link-rfc2396E"
href="mailto:tgl@sss.pgh.pa.us"><tgl@sss.pgh.pa.us></a>wrote: </pre><blockquote type="cite"><pre wrap="">We won't
callit anything, because we never will or can implement that.
 
See the theory of relativity: the notion of exactly simultaneous events   </pre></blockquote><pre wrap="">
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. </pre></blockquote><br /> Wouldn't this be serialized transactions?<br /><br
/>I'd like to see proof of some sort that PostgreSQL guarantees that the instant a 'commit' returns, any transactions
alreadyopen with the appropriate transaction isolation level, or any new sessions *will* see the results of the
commit.<br/><br /> I know that most of the time this happens - but what process synchronization steps occur to
*guarantee*that this happens?<br /><br /><blockquote
cite="mid:603c8f070812131835v7839b68fj736c853241cc7813@mail.gmail.com"type="cite"><pre wrap="">I just googled
"synchronousreplication" 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:

<a class="moz-txt-link-freetext"
href="http://code.google.com/p/google-mysql-tools/wiki/SemiSyncReplicationDesign">http://code.google.com/p/google-mysql-tools/wiki/SemiSyncReplicationDesign</a>

...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:

<a class="moz-txt-link-freetext"
href="http://www.cnds.jhu.edu/pub/papers/cnds-2002-4.pdf">http://www.cnds.jhu.edu/pub/papers/cnds-2002-4.pdf</a>

...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:

<a class="moz-txt-link-freetext"
href="http://en.wikipedia.org/wiki/Two-phase_commit_protocol">http://en.wikipedia.org/wiki/Two-phase_commit_protocol</a>

...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". </pre></blockquote><br /> Two phase commit doesn't imply that the transaction is guaranteed
tobe immediately visible. See my previous paragraph. Unless transactions are locked from starting until they are able
toprove that they have the latest commit (a feat which I'm going to theorize as impossible - because the moment you
waitfor a commit, and you begin again, you really have no guarantee that another commit has not occurred in the mean
time),I think it's clear that two phase commit guarantees that the commit has taken place, but does *not* guarantee
anythingabout visibility.<br /><br /> It might be a good bet - but guarantee? There is no such guarantee.<br /><br />
Cheers,<br/> mark<br /><br /><pre class="moz-signature" cols="72">-- 
 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>