Bill Moran wmoran at collaborativefusion.com
Mon Aug 6 06:33:33 PDT 2007
In response to "Dmitry Koterov" <dmitry at koterov.ru>:

> Hello.
> 
> Could you please answer three questions about Slony's transaction
> serialization? (I suppose that two first answers will be "yes", but I'd like
> to hear the opinions of gurus.) Unfortunately I cannot find direct answers
> in the Slony documentation.
> 
> 1. I have the following non-overlapped sequence of transactions in a SINGLE
> (!!!) session (connection) on an origin:
> 
> BEGIN;
> UPDATE tbl SET a=10 WHERE b=10;
> COMMIT;
> --
> -- some little delay (e.g. 0.1s)
> --
> BEGIN;
> UPDATE tbl SET a=20 WHERE b=20;
> COMMIT;
> 
> The question is: if a subscriber received and processed the result of the
> transaction #2, could I be sure that it had also received and committed a
> result of the transaction #1? Transactions are not overlapped.

I'm unsure what you mean by "non-overlapped".  The whole point to a transaction
is that it is an atomic operation, so, by design, transactions can't overlap,
since they happen within a single atom of time.

To answer your question, if you are sure that the transactions are committed
on the master in a particular order, you can then be sure that those are
committed on each of the slaves in the same order.  Otherwise, Slony wouldn't
even work.

> 2. I have the following sequence in a SINGLE session (also not overlapped):
> 
> BEGIN;
> UPDATE tbl SET c=10 WHERE d=10;
> COMMIT;
> --
> -- some delay (e.g. 0.1s)
> --
> SELECT nextval('some_seq');  -- => save a result to $some_seq variable
> 
> The question is: if subscriber's currval('some_seq') is greater than
> $some_seq, could I be sure that the transaction #1 is also processed and
> committed by this subscriber?

How is this question different than #1?

> 3. I have the following sequence in a SINGLE session (not overlapped):
> 
> BEGIN;
> UPDATE tbl SET c=10 WHERE d=10;
> COMMIT;
> --
> -- some delay (e.g. 0.1s)
> --
> SELECT max(sl_event.ev_seqno);  -- => save a result to $seqno variable
> 
> The question is: if subscriber's max(sl_event.ev_seqno) is greater than
> $seqno, could I be 100% sure that the transaction #1 is already processed
> and committed by this subscriber?

No.  That's not what that table does.  It simply replicates events to other
servers in the cluster, it doesn't guarantee that they've been processed.
Have a look at sl_confirm.

-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran at collaborativefusion.com
Phone: 412-422-3463x4023


More information about the Slony1-general mailing list