On 20.06.2012 21:51, Simon Riggs wrote:
> On 21 June 2012 02:32, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> I'm not saying that we need to implement all possible conflict resolution
>> algorithms right now - on the contrary I think conflict resolution belongs
>> outside core
>
> It's a pretty standard requirement to have user defined conflict
> handling, if that's what you mean.
>
> I'm OK with conflict handling being outside of core as a module, if
> that's what people think. We just need a commit hook. That is more
> likely to allow a workable solution with 9.3 as well, ISTM. It's
> likely to be contentious...
Hmm, what do you need to happen at commit time?
We already have RegisterXactCallback(), if that's enough...
>> BTW, one way to work around the lack of origin id in the WAL record header
>> is to just add an origin-id column to the table, indicating the last node
>> that updated the row. That would be a kludge, but I thought I'd mention it..
>
> err, I hope you mean that to be funny. (It wouldn't actually work either)
No, I wasn't serious that we should implement it that way. But now you
made me curious; why would it not work? If there's an origin-id column
in a table, it's included in every heap insert/delete/update WAL record.
Just set it to the current node's id on a local modification, and to the
origin's id when replaying changes from another node, and you have the
exact same information as you would with the extra field in WAL record
header.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com