From: Darren Johnson <djohnson@greatbridge.com>
Date: Tue, 12 Jun 2001 13:32:16 GMT
Message-ID: <20010612.13321600@j2.us.greatbridge.com>
Subject: Re: AW: Postgres Replication
To: The Hermit Hacker <scrappy@hub.org>
CC: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
	<pgsql-hackers@postgresql.org>
Reply-To: Darren Johnson <djohnson@greatbridge.com>
In-Reply-To: <Pine.BSF.4.33.0106120605130.411-100000@mobile.hub.org>
References: <Pine.BSF.4.33.0106120605130.411-100000@mobile.hub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit


> which I believe is what the rserv implementation in contrib currently 
does
> ... no?

We tried rserv, PG Link (Joseph Conway), and PosrgreSQL Replicator.  All
these projects are trigger based asynchronous replication.  They all have
some advantages over the current functionality of Postgres-R some of 
which I believe can be addressed:

1) Partial replication - being able to replicate just one or part of a
table(s)
2) They make no changes to the PostgreSQL code base. (Postgres-R can't 
address this one ;)
3) PostgreSQL Replicator has some very nice conflict resolution schemes.


Here are some disadvantages to using a "trigger based" approach:

1) Triggers simply transfer individual data items when they are modified,
they do not keep track of transactions.
2) The execution of triggers within a database imposes a performance 
overhead to that database.
3) Triggers require careful management by database administrators.  
Someone needs to keep track of all the "alarms" going off.
4) The activation of triggers in a database cannot be easily 
rolled back or undone.


> On Tue, 12 Jun 2001, Zeugswetter Andreas SB wrote:

> > Doing a replicate all or nothing approach that only works synchronous
> > is imho not flexible enough.
> >


I agree.  Partial and asynchronous replication need to be addressed, 
and some of the common functionality of Postgres-R could possibly 
be used to meet those needs. 
 

Thanks for your feedback,

Darren