Thanks for your kind reply. Actually what I mean 'atomic' is that, for example, if on parent, update table A and table B, then slony trigger replication on slave node, update table A succeed, however update table B fail, can slony rollback the table A?
On Wed, Aug 26, 2009 at 9:07 PM, Stuart Bishop <[email protected]>wrote: > 2009/8/26 Han He <[email protected]>: > > > I encounter a problem when using slony. I had a transaction that updated > > both table A and table B. This is atomic transaction. While slony is > doing > > the replication, on parent, the transaction is done, on slave node, there > > might exists error which cause the transaction error. That’s to say, on > > slave node, table A is updated while table B is not updated. This will > cause > > problem to our application. Is there any way in slony to keep the > > transaction atomic? > > If table A and table B are in the same replication set, the update is > atomic on the slave node too. > > Of course, if this situation does happen (lack of disk space for > instance), replication stops and your slave lags until you fix the > problem. > > > > -- > Stuart Bishop <[email protected]> > http://www.stuartbishop.net/ >
_______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
