RE: AW: Postgres Replication

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