Re: Sync Rep: First Thoughts on Code

On Sun, 2008-12-14 at 13:31 +0900, Tatsuo Ishii wrote:
> > The point here is that synchronous replication, at least to some
> > people, is going to imply that the user-visible states of the two
> > copies are consistent.  To other people, it is going to imply that
> > committed transactions will never be lost even in the event of a
> > catastropic loss of the primary 1 picosecond after the commit is
> > acknowledged.  We need to choose some word that implies that we are
> > guaranteeing the latter of these two things but not the former.
> > Otherwise, we will have confused users, and terminological confusion
> > when and if we ever implement the former as well.
> 
> Right. Before watching this thread, I had thought that the log
> shipping sync replication behaves former (and I had told so to people
> in Japan who are interested in 8.4 development. Of course this is my
> fault, though).
> 
> Now I understand the log shipping sync replication does not behave
> same as other "sync replications" such as pgpool and PGCluster (there
> maybe more, but I don't know)

GENERAL COMMENTS, not to anybody in particular:


'Tis but thy name that is my enemy.
...
What's in a name? That which we call a rose
By any other name would smell as sweet.
...

Juliet, from "Romeo and Juliet"


I am truly lost to understand why the *name* "synchronous replication"
causes so much discussion, yet nobody has discussed what they would
actually like the software to *do* (this being a software discussion
list...). AFAICS we can make the software behave like *any* of the
definitions discussed so far.

It is certainly far too early to say what the final exact behaviour will
be and there is no reason at all to pre-suppose that it need only be a
single behaviour. I'm in favour of options, generally, but I would say
that the distinction between some of these options is mostly very fine
and strongly doubt whether people would use them if they existed. *But*
I think we can add them at a later stage of development if requirements
genuinely exist once all the benefits *and* costs are understood.

I would also point out that the distinction made between various
meanings of synchronous is *only* important if Hot Standby is included
as well. And that is closely linked to the replication feature, which we
really need to complete first. We have much to do yet.

So let's please end the name debate there and think about software.

...

We can make the reply to a commit message when any of the following
events have occurred

1. We sent the message to standby
2. We received the message on standby
3. We wrote the WAL to the WAL file
4. We fsync'd the WAL file
5. We CRC checked the WAL commit record
6. We applied the WAL commit record

Now you might think from what people have said that having synchronised
contents on both primary and standby is the only way to achieve exactly
the same results to queries on both nodes. Another way is to utilise a
snapshot taken on the primary and simply wait until the standby catches
up with that snapshot's LSN. So there is more than one way of achieving
a particular result and it is not dependent upon the exact
synchronisation we employ at commit time.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support