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. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
