Re: terms for database replication: synchronous vs eager

On 9/7/2007 11:01 AM, Markus Schiltknecht wrote:
> Hi,
>
> I'm asking for advice and hints regarding terms in database replication,
> especially WRT Postgres-R. (Sorry for crossposting, but I fear not
> reaching enough people on the Postgres-R ML alone)
>
> I'm struggling on how to classify the Postgres-R algorithm. Up until
> recently, most people thought of it as synchronous replication, but it's
> not synchronous in the strong (and very common) sense. I.e. after a node
> confirms to have committed a transaction, other nodes didn't necessarily
> commit already. (They only promise that they *will* commit without
> conflicts).
>
> This violates the common understanding of synchrony, because you can't
> commit on a node A and then query another node B and expect it be
> coherent immediately.

That's right. And there is no guarantee about the lag at all. So you can
find "old" data on node B long after you committed a change to node A.

> None the less, Postgres-R is eager (or pessimistic?) in the sense that
> it replicates *before* committing, so as to avoid divergence. In [1]
> I've tried to make that distinction clear, and I'm currently advocating
> for using synchronous only in the very strong (and commonly used) sense.
> I've choosen the word 'eager' to mean 'replicates before committing'.
>
> According to that definitions, Postgres-R is async but eager.

Postgres-R is an asynchronous replication system by all means. It only
makes sure that the workset data (that's what Postgres-R calls the
replication log for one transaction) has been received by a group
communication system supporting total order and that the group
communication system decided it to be the transaction that (logically)
happened before any possibly conflicting concurrent transaction.

This is the wonderful idea how Postgres-R will have a failsafe conflict
resolution mechanism in an asynchronous system.

I don't know what you associate with the word "eager". All I see is that
Postgres-R makes sure that some other process, which might still reside
on the same hardware as the DB, is now in charge of delivery. Nobody
said that the GC implementation cannot have made the decision about the
total order of two workset messages and already reported that to the
local client application before those messages ever got transmitted over
the wire.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #