Han He wrote:
> 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.
Yes and no Han.

Yes, the transaction does not go over the wire until the COMMIT happens
on the master.

No, if one or more of the updates fail on the slave the master will not
be rolled back (since there is no lock held on the master until the
slave(s) update to force that to happen - consider that the master could
have processed hundreds of ADDITIONAL transactions before the first one
gets to all the slaves and finishes.)  If that occurs then the slave
will effectively stop accepting further updates, so it will be "as the
master was at the time the first attempt failed" until the condition
that causes the failure (e.g. disk full) is cleared.

SLONY sends over a block of updates/changes as a transaction, with the
count of "how many" are in a block being determined by when the
transaction snapshots are taken (I and others use a timed job that
forces segregation to prevent an outage creating one monster transaction
that might never get across the wire, or might not for long enough as to
be effectively never.)

You can count on Slony guaranteeing ordering of changes on the slaves,
but not whether there is or is not a lag of some variable amount of time
between master and slave.

For my applications this is ok (if I look at a slave and see "as it was
2 minutes ago" that's not a problem) but it might be for your application.

You have to be very careful in an updating application to be sure that
you don't post conflicting updates from two sources at once (or before
the first one can propagate) with an inconsistent view between what's on
the slave and what's on the master - this CAN happen if you don't pay
close attention to what you're doing.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: karl.vcf
Type: text/x-vcard
Size: 265 bytes
Desc: not available
Url : http://lists.slony.info/pipermail/slony1-general/attachments/20090826=
/5c853c65/karl.vcf