Robert Haas wrote:
On Sat, Dec 13, 2008 at 1:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
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.
Wouldn't this be serialized transactions?
I'd like to see proof of some sort that PostgreSQL guarantees that the
instant a 'commit' returns, any transactions already open with the
appropriate transaction isolation level, or any new sessions *will* see
the results of the commit.
I know that most of the time this happens - but what process
synchronization steps occur to *guarantee* that this happens?
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".
Two phase commit doesn't imply that the transaction is guaranteed to be
immediately visible. See my previous paragraph. Unless transactions are
locked from starting until they are able to prove that they have the
latest commit (a feat which I'm going to theorize as impossible -
because the moment you wait for 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 anything about visibility.
It might be a good bet - but guarantee? There is no such guarantee.
Cheers,
mark
--
Mark Mielke <m...@mielke.cc>
