Re: AW: Postgres Replication

> 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