On Wed, 3 Mar 2010 10:08:01 -0500, Greg Sabino Mullane <greg(at)endpoint(dot)com>
> Well, it's all open source for the looking. :) Here's a quick summary.
> Basically, Bucardo supports two types of conflict resolution: standard
> and custom. The standard includes a handful of default rules about which
> side (let's call them A and B) should "win" in a conflict. Options
> include 'source' (A), 'target' (B), 'latest' (who made the most recent
> change), and 'random' (call it a really weird form of load balancing :).
> The custom handlers are much more interesting, as it can incroporate
> business logic. Basically, you write a perl subroutine that gets fed
> information about the current conflict and returns a code indicating
> which side should win. The passed in information also includes handles
> to both sides, so that you can query other tables, and even update
> the rows in conflict directly. I don't know if any of that is really
> applicable to something like Postgres-R, but maybe that's one of the
> things we can talk about.
Thank you for this quick summary (it's vastly more efficient than having
to study source code ;-) ).
For Postgres-R, I'm having something akin to your custom handlers in mind.
Maybe we can even come up with a compatible interface? I'll certainly have
a look at bucardo's custom (conflict resolution) handler interface.
In response to
pgsql-cluster-hackers by date
|Next:||From: Josh Berkus||Date: 2010-03-03 17:42:22|
|Subject: Re: Spec discussion: Generalized Data Queue
/ Modification Trigger|
|Previous:||From: Greg Sabino Mullane||Date: 2010-03-03 15:08:01|
|Subject: Re: PgCon: who will be there?|