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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
