That should not happen; how does Table B's update fail other than a hardware problem (in which case replication is blown anyway)?
If there was to be a disk full condition Table Bs update would fail but the transaction would not commit; ergo, if you cleared space on the disk (assuming everything remained running) that transaction should remain "pending" and be retried. Are you referring to this situation? BEGIN Change Table 1 Change Table 2 COMMIT On the master, yet when this goes over-wire Table 2s update fails? Other than the disk running out of space or the machine crashing (in both cases the TABLE 2 update is not lost, it is, however, deferred) yes, there's a problem. But that problem is transient in that the update is not lost; it is, however, deferred until the condition preventing the commit is cleared. Of note everything BEHIND that change is also deferred since the changes are serialized so no update after the failed one will propagate until the failed one does so. If you're talking about transaction idempotence (that is, if Table 1 change is "visible" on the slave than Table 2's must be) then unless I misunderstand how SLONY works it is not intended to nor does it protect the idempotence of transactions across the wire. If transaction idempotence is required then you need to query the master. Han He 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? > > On Wed, Aug 26, 2009 at 9:07 PM, Stuart Bishop > <[email protected] <mailto:[email protected]>> wrote: > > 2009/8/26 Han He <[email protected] <mailto:[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] > <mailto:[email protected]>> > http://www.stuartbishop.net/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Slony1-general mailing list > [email protected] > http://lists.slony.info/mailman/listinfo/slony1-general >
begin:vcard fn:Karl Denninger n:Denninger;Karl org:Cuda Systems LLC adr;dom:;;314 Olde Post Road;Niceville;FL;32578 email;internet:[email protected] tel;work:850-376-9364 tel;fax:850-897-9364 x-mozilla-html:TRUE url:http://market-ticker.org version:2.1 end:vcard
_______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
