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 <stuart at stuartbishop.net>wr=
ote:

> On Wed, Aug 26, 2009 at 9:14 PM, Han He<hansfly at gmail.com> 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, upda=
te
> > 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 <stuart at stuartbishop.net>
> http://www.stuartbishop.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20090826/=
638f754e/attachment.htm