Hi All,
 
I have a 4 node test setup. It is very simple, with one set, containing one table. The origin is node 1. The view of sl_listen is as below. All nodes listen for events directly from the origin node of an event. (i.e. provider of events from node 3 is always node 3). Great so far..
 
li_origin | li_provider | li_receiver
-----------+-------------+-------------
         1 |           1 |           2
         1 |           1 |           3
         1 |           1 |           4
         2 |           2 |           1
         2 |           2 |           3
         2 |           2 |           4
         3 |           3 |           1
         3 |           3 |           2
         3 |           3 |           4
         4 |           4 |           1
         4 |           4 |           2
         4 |           4 |           3

After issuing a move set from node 1 to node 2 (which was successful) the listen table now looks like this:
 
 li_origin | li_provider | li_receiver
-----------+-------------+-------------
         1 |           1 |           2
         1 |           1 |           3
         1 |           1 |           4
         2 |           2 |           1
         2 |           1 |           3
         2 |           1 |           4
         3 |           3 |           1
         3 |           3 |           2
         3 |           3 |           4
         4 |           4 |           1
         4 |           4 |           2
         4 |           4 |           3

All db changes now happen in node 2, but instead of listening to node 2 directly, nodes 3 and 4 are getting the changes via provider node 1. This is not what I had expected, as presumeably the point of moving set is quite often to then take down the old origin. Anyway, I thought no worries, I'll just send a couple of store path commands to get nodes 3 and 4 listening to node 2 directly.
 
I did this using
<slon preamble>
store listen (origin=2, provider=2, receiver=3);
store listen (origin=2, provider=2, receiver=4);

This seemed to have no effect at all and I can't see any evidence of the store listen commands being processed. 
 
Is what I am doing correct? Is it possible to now get nodes 3 and 4 listening directly to node 2, so I can drop node 1 from the replication completely?
 
Thanks for your help,
Vicki
 
 
 
 


This message should be regarded as confidential. If you have received this 
email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy 
by an authorized signatory.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060704/1833ccb2/attachment.html