Skip site navigation (1) Skip section navigation (2)

Re: Proposal: Commit timestamp

From: Markus Schiltknecht <markus(at)bluegap(dot)ch>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Commit timestamp
Date: 2007-01-26 10:36:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Jan Wieck wrote:
> The replication system I have in mind will have another field type of 
> the balance nature, where it will never communicate the current value 
> but only deltas that get applied regardless of the two timestamps.

I'd favor a more generally usable conflict resolution function 
interface, on top of which you can implement both, the "last update 
wins" as well as the "balance" conflict resolution type.

Passing the last common ancestor and the two conflicting heads to the 
conflict resolution function (CRF) should be enough. That would easily 
allow to implement the "balance" type (as you can calculate both 
deltas). And if you want to rely on something as arbitrary as a 
timestamp, you'd simply have to add a timestamp column to your table and 
let the CRF decide uppon that.

This would allow pretty much any type of conflict resolution, for 
example: higher priority cleanup transactions, which change lots of 
tuples and should better not be aborted later on. Those could be 
implemented by adding a priority column and having the CRF respect that 
one, too.

To find the last common ancestor tuple, transaction ids and MVCC are 
enough. You wouldn't need to add timestamps. You'd only have to make 
sure VACUUM doesn't delete tuples you still need.



In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2007-01-26 10:54:25
Subject: Re: Proposal: Commit timestamp
Previous:From: BluDesDate: 2007-01-26 10:22:37
Subject: PostgreSQL Data Loss

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group