From: =?utf-8?q?Jos=C3=A9_Orlando_Pereira?= <jop@lsd.di.uminho.pt>
Organization: http://gsd.di.uminho.pt/members/jop
To: pgsql-hackers@postgresql.org
Subject: Re: standard interfaces for replication providers
Date: Fri, 4 Aug 2006 17:33:23 +0100
User-Agent: KMail/1.9.3
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "Jonah H. Harris" <jonah.harris@gmail.com>,
	"alfranio correia junior" <alfranio@lsd.di.uminho.pt>
References: <44D30B31.2070403@lsd.di.uminho.pt>
	<36e682920608040645o56ea4bb0l21451c2a73f0e1a3@mail.gmail.com>
	<29263.1154706412@sss.pgh.pa.us>
In-Reply-To: <29263.1154706412@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200608041733.24228.jop@lsd.di.uminho.pt>

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