From: Darren Johnson <djohnson@greatbridge.com>
Date: Tue, 12 Jun 2001 18:29:20 GMT
Message-ID: <20010612.18292000@j2.us.greatbridge.com>
Subject: RE: AW: Postgres Replication
To: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
CC: The Hermit Hacker <scrappy@hub.org>, Zeugswetter Andreas SB
	<ZeugswetterA@wien.spardat.at>, pgsql-hackers@postgresql.org
Reply-To: Darren Johnson <djohnson@greatbridge.com>
In-Reply-To: 
 <3705826352029646A3E91C53F7189E32016670@sectorbase2.sectorbase.com>
References: 
 <3705826352029646A3E91C53F7189E32016670@sectorbase2.sectorbase.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit


> > 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.

> I don't know about other *async* replication engines but Rserv
> keeps track of transactions (if I understood you corectly).
> Rserv transfers not individual modified data items but
> *consistent* snapshot of changes to move slave database from
> one *consistent* state (when all RI constraints satisfied)
> to another *consistent* state.

I thought Andreas did a good job of correcting me here. Transaction-
based replication with triggers do not apply to points 1 and 4.  I
should have made a distinction between non-transaction and 
transaction based replication with triggers.  I was not trying to
single out rserv or any other project, and I can see how my wording 
implies this misinterpretation (my apologies).
 

> > 4) The activation of triggers in a database cannot be easily
> > rolled back or undone.

> What do you mean?

Once the trigger fires, it is not an easy task  to abort that 
execution via rollback or undo.  Again this is not an issue 
with a transaction-based trigger approach.


Sincerely,

Darren