http://www.slony.info/bugzilla/show_bug.cgi?id=314

--- Comment #3 from Steve Singer <ssinger at ca.afilias.info> 2013-09-09 08:44:59 PDT ---
I still don't understand why you think slony isn't behaving as it should.

You have triggers installed on the node '.200' but not the node '.247'.



echo 'insert into test_slony.slave_a values (1,1);' | psql -h 192.168.1.247
-d SLAVE
INSERT 0 1

Inserts a row into slave_a in .247 directly.  None of your user triggers fire
on .247.
This row then replicates to .200.  When the row is inserted into slave_a on
.200 the slave_a_trigger will run on .200 inserting a row into the 'master'
table.
The slony log trigger will *NOT* run on this node because the default state of
the logTrigger is 'ENABLED' and session_replication_role is replica.

The second insert then runs 'insert into test_slony.slave_b values (1,1);' |
psql -h 192.168.1.200

This inserts a row into slave_b and the slave_b_trigger runs which inserts a
row into the 'master' table on .200.   The logTrigger does fire.  The table
'slave_b' is NOT replicated but the table 'master' is.   This results in a row
being added to the table 'master' on the .247 machine via slony.  No triggers
will run on .247

This means that
.247 should have 1 row in slave_a from the first insert and 1 row in 'master'
from the second insert

.200 will have 1 row in slave_a from the first insert,  2 rows in 'master' ,
one from each insert, and 1 row in slave_b from the second insert.

This matches your output doesn't it?

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.