Robert,
> 1.) Partial replication.
> 2.) WAN replication.
> 3.) Bi-directional replication. (Yes, this is evil but there are
> problems where it is indispensable.)
> 4.) Upgrade support. Aside from database upgrade (how would this ever
> really work between versions?), it would not support zero-downtime app
> upgrades, which depend on bi-directional replication tricks.
> 5.) Heterogeneous replication.
> 6.) Finally, performance scaling using scale-out over large numbers of
> replicas. I think it’s possible to get tunnel vision on this—it’s not a
> big requirement in the PG community because people don’t use PG in the
> first place when they want to do this. They use MySQL, which has very
> good replication for performance scaling, though it’s rather weak for
> availability.
Let's not try to boil the ocean, hey?
From my perspective, the above use cases are what complex tools like
Slony, Bucardo, Skytools, Continuent, pgCluster, pgPool2, etc., etc. are
for. Now, if you're saying that you want to develop row-based
replication so that Continuent will work better, I'm all for it; but
saying that we *shouldn't* implement the current spec which satisfies
large numbers of users because it doesn't support *all* users is a
recipe for self-defeat. We can't satisfy all users with one
implementation, and we shouldn't try.
I think, for that matter, that work on the common replication hooks
supporting the external replication packages should continue. We need
these for precisely the reasons you state. But ... single-master,
single-slave, synch or asynch, whole-installation local network
replication is a case which covers a *lot* of users' needs ... I'd argue
the numerical majority.
--Josh
