Re: Sync Rep: First Thoughts on Code

Robert Haas wrote:
> On Sat, Dec 13, 2008 at 1:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 <mark(at)mielke(dot)cc>