I meant rollback table A on the slave. Your answer is very useful. The transaction will be atomic if table A and table B in the same replication set. That's what I want. Thanks a lot.
On Wed, Aug 26, 2009 at 10:29 PM, Stuart Bishop <[email protected]>wrote: > On Wed, Aug 26, 2009 at 9:14 PM, Han He<[email protected]> wrote: > > 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? > > rollback table A on the master or the slave? > > With Slony, the following sequence happens when table A and table B > are in the same replication set: > > On master: > begin; > update A set ....; > update B set ...; > commit; > > [time passes] > > On slave: > begin; > update A set ...; > update B set ...; > commit; > > The updates on the slave do not start until after the transaction on > the master has committed. > > So if you want the updates on the master be rolled back if the updates > on the slave fail, you cannot do that with an asynchronous replication > system like Slony. You need a synchronous replication system like > pgpool. > > If you mean will the table A update on the slave be rolled back, that > is what happens. If you do not see this behavior, then either the > tables are in separate replication sets, or the updates on the master > were not atomic (perhaps the client was in auto commit mode?). > > > -- > Stuart Bishop <[email protected]> > http://www.stuartbishop.net/ >
_______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
