Jan, thanks for great answers!
Seems all that is for Slony FAQ. Especially - about never-splitable
transactions.

On 7/19/07, Jan Wieck <JanWieck at yahoo.com> wrote:
>
> On 7/18/2007 3:50 PM, Andrew Sullivan wrote:
> > On Wed, Jul 18, 2007 at 11:06:44PM +0400, Dmitry Koterov wrote:
> >> Sorry, but I have not undersand this clearly. :-(
> >> Could you please answer the single practical question (just "yes" or
> "no"):
> >> if I perform
> >>
> >> BEGIN;
> >> INSERT INTO tbl(id, parent_id) VALUES(1, 2);    -- child first!
> >> INSERT INTO tbl(id, parent_id) VALUES(2, null);  -- parent
> >> COMMIT;
> >>
> >> on master (assuming that parent_id foreign key is deferrable), DOES
> Slony
> >> GUARANTEE that ANY subscriber will receive and SUCESSFULLY process this
> >> data, or there is a probability that a subscriber will fail to update?
> >
> > Yes, but I'm not sure whether in your example
> > statement1(tbl)=3D=3Dstatement2(tbl).
> >
> > Foreign keys are disabled on the replica on the grounds that they're
> > enforced on the origin anyway.  But your case isn't a foreign key,
> > AFAICT, because the tables are the same one in each statement as I
> > read it.
>
> That would be a self referencing table and still a foreign key. And for
> sure can someone use a deferrable constraint in that case to allow
> inserting self referencing rows out of order. Nothing wrong with the
> example.
>
> To answer Dimitry's questions, first all changes done by one transaction
> on the origin will be replicated in the same slon transaction on a
> subscriber. It is possible that multiple origin transactions are grouped
> together into one replication transaction on serializable snapshot
> visibility boundaries. But the actions of a single origin transaction
> are never split into multiple replication transactions. This means that
> there will never be a state on a subscriber that would not have been
> visible under MVCC rules on the origin in precisely a SYNC events
> transaction. Unless one uses READ DIRTY isolation, of course.
>
> Second foreign key constraints are internally implemented with triggers
> in Postgres. Since Slony disables triggers on a replica, the simple
> answer is that foreign keys are not checked on replicated tables on a
> slave.
>
>
> Jan
>
> --
> #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.                                  #
> #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D JanWieck at Yahoo.com #
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20070719/=
c75bfdbe/attachment.htm