Re: [Postgres-xc-developers] Replicated update and delete

[鈴木 幸市 <ko...@in...>]

Also, to remove serious danger associated with the current TRIGGER, I think we should apply Mason’s patch at least to 1.1.    We should release 1.1.1 prior to 1.2.0.

Thoughts?
---
Koichi Suzuki

2014/02/13 1:18、Mason Sharp <ms...@tr...<mailto:ms...@tr...>> のメール：



I’m afraid it takes long effort to fix all the influences of this change.   How do you think about this?    As I noted, approach C has good point.   The issue is how long it takes.   With approach B, we can easily change this handling to approach C.   I’d like to have you opinion on this.

It seems unnecessary if the table already has a primary key or unique index. Anyway, approach C is the approach that I originally took with GridSQL/Stado, adding something called xrowid, but we later disabled it by default.

Was there any other reason of disabling it other than code simplicity and maintainability?

Yes. We could have saved time and worked on other things.


In hindsight I would have saved the trouble and not implemented it to keep the code simpler and easier to maintain, and just left it up to the user to use a key.

To summarize, I would go with B.

What is your stance on the fact that going with option B makes us backward in-compatible?

Right now the situation is not good. Better to make it backward incompatible than to have data issues. I also don't believe the user base is too big as of yet to cause too many people headaches.

Also, other RDBMSs require primary keys for replication. IIRC even Slony requires one.


--
Mason Sharp

TransLattice - http://www.translattice.com<http://www.translattice.com/>
Distributed and Clustered Database Solutions