Re: Proposal: Commit timestamp

On 2/7/2007 2:37 AM, Markus Schiltknecht wrote:
> Hi,
>
> Jan Wieck wrote:
>> 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.
>
> It helps to categorize these conflict types. There basically are:

Are we still discussing if the Postgres backend may provide support for
a commit timestamp, that follows the rules for Lamport timestamps in a
multi-node cluster? It seems more like we are drifting into what type of
replication system I should design to please most people.

Jan

>
> * data conflicts: simple row data, i.e. update - update conflicts.
>
> * uniqueness conflicts: two rows conflict because they'd violate a
> uniquenes constraint, i.e. insert - insert, update - insert or update -
> update.
>
> * visibility conflicts: basically the remaining update - delete and
> delete - delete cases. But also SELECT FOR UPDATE candidates, etc...
> Everything having to do with a rows not yet or no longer being visible
> to a transaction.
>
> Your example certainly involves a visibility conflict (update - delete).
> Not even (sync) Postgres-R can guarantee consistency on the visibility
> level, i.e. a first transaction's SELECT FOR UPDATE might not see some
> just recently committed transactions newly inserted rows (because that
> one isn't replayed yet on the node, thus the transaction is working on
> an 'old' snapshot of the database state). Another simpler example:
> Postgres-R doesn't raise a serialization error on delete-delete
> conflicts, it simply deletes the row once, even if two transactions
> confirmed to have committed a transaction which deleted a row.
>
> Luckily, most applications don't need that anyway, though.
>
>> The solution is simple, reinsert the deleted item ...
>
> ..at which point timestamps certainly won't help :-) Sorry, couldn't
> resist...
>
>> 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.
>
> Huh? Are you planning on aborting *parts* of a transaction? I didn't
> think about that, but my gut feeling is that you don't want to do that.
>
>> 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).
>
> You'd have to elaborate on that...
>
>> 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.
>
> Sure. I know, discussions about replication can get endless, probably
> even are so by definition ;-) But hey, they're fun!
>
>> 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.
>
> Like the one which would result from a merge of such an async
> replication with a sync one? Imagine being able to choose between sync
> and async per transaction...
>
> Regards
>
> Markus
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org

--
#======================================================================#
# 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 #