Hi, Karl

Thanks a lot for your patient and helpful explanation. I do not quite
understand the mechanism of slony. I am a newbie on slony. From the previous
replies of you and others, I have the following conclusion. Am I right?

SLONY sends over a block of updates/changes as a transaction. In one
transaction, "a block of update/changes" is committed as a whole. The
scenario that one update/change succeed and others fail never happen.

Then I have another question.

Once there exists a block of updates/changes that application take them as a
whole. However if SLONY split them into two or more transactions. On the
slave node, one transaction succeed, while another might fail because of
network problem.

It seems this problem turns out to be that whether SLONY can define a
transaction clearly. Or how frequent does SLONY construct a transaction?

>From your last reply, you mean "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.".
How could I define a timed job for SLONY?


Thanks&Regards
Han He

On Wed, Aug 26, 2009 at 10:57 PM, Karl Denninger <karl at denninger.net> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20090826/=
9cd08d4d/attachment-0001.htm