pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: José Orlando Pereira <jop@lsd.di.uminho.pt>
To: pgsql-hackers@postgresql.org
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jonah H. Harris <jonah.harris@gmail.com>
Cc: alfranio correia junior <alfranio@lsd.di.uminho.pt>
Subject: Re: standard interfaces for replication providers
Date: Fri, 4 Aug 2006 17:33:23 +0100
Message-ID: <200608041733.24228.jop@lsd.di.uminho.pt> (raw)
In-Reply-To: <29263.1154706412@sss.pgh.pa.us>
References: <44D30B31.2070403@lsd.di.uminho.pt>
	<36e682920608040645o56ea4bb0l21451c2a73f0e1a3@mail.gmail.com>
	<29263.1154706412@sss.pgh.pa.us>

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



view thread (21+ messages)  latest in thread

Message-ID: <200608041733.24228.jop@lsd.di.uminho.pt>
Permalink:  ../200608041733.24228.jop@lsd.di.uminho.pt/
Also on:    postgresql.org/message-id/200608041733.24228.jop@lsd.di.uminho.pt

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: jop@lsd.di.uminho.pt, tgl@sss.pgh.pa.us, jonah.harris@gmail.com, alfranio@lsd.di.uminho.pt
  Subject: Re: standard interfaces for replication providers
  In-Reply-To: <200608041733.24228.jop@lsd.di.uminho.pt>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox