On 2/6/2007 11:44 AM, Markus Schiltknecht wrote:

Zeugswetter Andreas ADI SD wrote:
And "time based"
is surely one of the important conflict resolution methods for async MM

That's what I'm questioning. Wouldn't any other deterministic, but seemingly random abort decision be as clever as time based conflict resolution? It would then be clear to the user that it's random and not some "in most cases time based, but no in others and only if..." thing.

Sure there are others, like "rule based" "priority based" but I think
you don't need additional backend functionality for those.

Got the point, yes. I'm impatient, sorry.

Neither the less, I'm questioning if is it worth adding backend functionality for that. And given this probably is the most wanted resolution method, this question might be "heretical". You could also see it as sort of an user educating question: don't favor time based resolution if that's the one resolution method with the most traps.

These are all very good suggestions towards additional conflict resolution mechanisms, that solve one or the other problem. As we have said for years now, one size will not fit all. What I am after for the moment is a system that supports by default a last update wins on the row level, where last update certainly is a little fuzzy, but not by minutes. Plus balance type columns. A balance column is not propagated as a new value, but as a delta between the old and the new value. All replica will apply the delta to that column regardless of whether the replication info is newer or older than the existing row. That way, literal value type columns (like an address) will maintain cluster wide the value of the last update to the row, while balance type columns will clusterwide maintain the sum of all changes.

Whatever strategy one will use, in an async multimaster there are always cases that can be resolved by rules (last update being one of them), and some that I can't even imagine solving so far. I guess some of the cases will simply boil down to "the application has to make sure that ... never occurs". Think of a multi-item order, created on one node, while another node is deleting the long unused item (which would have to be backordered). Now while those two nodes figure out what to do to make this consistent again, a third node does a partial shipment of that order. The solution is simple, reinsert the deleted item ... only that there were rather nasty ON DELETE CASCADE's on that item that removed all the consumer reviews, product descriptions, data sheets and what not. It's going to be an awful lot of undo.

I haven't really made up my mind about a user defined rule based conflict resolution interface yet. I do plan to have a unique and foreign key constraint based, synchronous advisory locking system on top of my system in a later version (advisory key locks would stay in place until the transaction, that placed them, replicates).

I guess you see by now why I wanted to keep the discussion about the individual, rather generic support features in the backend separate from the particular features I plan to implement in the replication system. Everyone has different needs and consequently an async multi-master "must" do a whole range of mutually exclusive things altogether ... because Postgres can never accept a partial solution. We want the egg laying milk-wool-pig or nothing.


# 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 6: explain analyze is your friend

Reply via email to