On 20 June 2012 16:44, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 20.06.2012 11:34, Simon Riggs wrote: >> >> On 20 June 2012 16:23, Heikki Linnakangas >> <heikki.linnakan...@enterprisedb.com> wrote: >> >>> It's only needed for multi-master replication, where the same table can >>> be >>> updated from multiple nodes. Just leave that out for now. There's plenty >>> of >>> functionality and issues left even without that. >> >> >> Huh? Multi-master replication is what is being built here and many >> people want that. > > > Sure, but presumably you're going to implement master-slave first, and build > multi-master on top of that. What I'm saying is that we can leave out the > origin-id for now, since we don't have agreement on it, and revisit it after > master-slave replication is working.
I am comfortable with the idea of deferring applying the patch, but I don't see any need to defer agreeing the patch is OK, so it can be applied easily later. It does beg the question of when exactly we would defer it to though. When would that be? If you have a reason for disagreement, please raise it now, having seen explanations/comments on various concerns. Of course, people have made initial objections, which is fine but its not reasonable to assume that such complaints continue to exist after. Perhaps there are other thoughts? The idea that logical rep is some kind of useful end goal in itself is slightly misleading. If the thought is to block multi-master completely on that basis, that would be a shame. Logical rep is the mechanism for implementing multi-master. Deferring this could easily end up with a huge patch in last CF, and then it will be rejected/deferred. Patch submission here is following the requested process - as early as possible, production ready, small meaningful patches that build towards a final goal. This is especially true for format changes, which is why this patch is here now. Doing it differently just makes patch wrangling and review more difficult, which reduces overall quality and slows down development. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers