On Friday 04 August 2006 16:46, Tom Lane wrote:
> We haven't been able to build production-grade multi-master replication
> without the barrier of a "standard" database-agnostic API, so I kinda
> doubt that it will work all that much better with one. See Slony-II.
I would argue that people haven't been able to build production-grade
multi-master replication, in part, due to the barrier of not having
a "standard" database-agnostic API. :-)
In fact, the problem is not the lack of a "standard" API but the lack of an
API at all. Having to learn the intrincacies of a database server (or build a
full fledged server wrapper) to experiment with simple prototypes is a
serious hurdle for R&D in database replication. This has been the case for
replication based on group communication.
> In short the burden of proof is to show why this should go in, not why not.
Please don't confuse two proposals included in the distributed package:
(1) A PostgreSQL specific patch, which implements a minimal set of required
features with a PostgreSQL-specific interface (e.g. triggers, new statements,
configuration variables). This is by no means a "standard" interface. The
included technical report discusses why these are required for a variety of
replication scenarios.
(2) A DBMS independent "standard" Java interface, which is easily built on
the modified PostgreSQL server using both existing features (e.g. normal
triggers) and those introduced by (1). Included toy applications show how
this would be useful for replication, but we are not (yet) pushing for its
adoption.
> (Suitable proof would be a usable replication system built atop it...)
I agree. ;)
--
Jose Orlando Pereira