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.



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to