On Thu, Oct 2, 2014 at 4:49 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > An origin column in the table itself helps tremendously to debug issues with > the replication system. In many if not most scenarios, I think you'd want to > have that extra column, even if it's not strictly required.
I like a lot of what you wrote here, but I strongly disagree with this part. A good replication solution shouldn't require changes to the objects being replicated. The triggers that Slony and other current logical replication solutions use are a problem not only because they're slow (although that is a problem) but also because they represent a user-visible wart that people who don't otherwise care about the fact that their database is being replicated have to be concerned with. I would agree that some people might, for particular use cases, want to include origin information in the table that the replication system knows about, but it shouldn't be required. When you look at the replication systems that we have today, you've basically got streaming replication, which is high-performance and fairly hands-off (at least once you get it set up properly; that part can be kind of a bear) but can't cross versions let alone database systems and requires that the slaves be strictly read-only. Then on the flip side you've got things like Slony, Bucardo, and others. Some of these allow multi-master; all of them at least allow table-level determination of which server has the writable copy. Nearly all of them are cross-version and some even allow replication into non-PostgreSQL systems. But they are slow *and administratively complex*. If we're able to get something that feels like streaming replication from a performance and administrative complexity point of view but can be cross-version and allow at least some writes on slaves, that's going to be an epic leap forward for the project. In my mind, that means it's got to be completely hands-off from a schema design point of view: you should be able to start up a database and design it however you want, put anything you like into it, and then decide later that you want to bolt logical replication on top of it, just as you can for streaming physical replication. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
