Hi,

I've encountered some unusual behavior in v 1.2.11 (pg819 on AIX),  
though I can't swear that it is unique to this release.

The scenario is as follows:

There are four nodes, 8143, 8142, 8194, and 8141.  Node 8143 is the 
origin for set1.  Node 8142 is directly subscribed to the origin, as is 
8194.  Node 8141 cascades from 8142.  The state of sl_listen, where 8141 
is a receiver, is as follows:


oxrsorg=# SELECT * from _oxrsorg.sl_listen where li_receiver = 8141 
order by li_origin;
 li_origin | li_provider | li_receiver
-----------+-------------+-------------
      8142 |        8143 |        8141
      8142 |        8194 |        8141
      8142 |        8142 |        8141
      8143 |        8142 |        8141
      8194 |        8142 |        8141
      8194 |        8194 |        8141
      8194 |        8143 |        8141
(7 rows)


If I add an additional set, with origin 8143, then subscribe 8141 
directly to it, the listen path between 8143 and 8141 goes away:

include <cluster.preamble>

SUBSCRIBE SET (ID = 2, PROVIDER = 8143, RECEIVER = 8141, FORWARD = YES);

oxrsorg=# SELECT * from _oxrsorg.sl_listen where li_receiver = 8141 
order by li_origin;
 li_origin | li_provider | li_receiver
-----------+-------------+-------------
      8142 |        8142 |        8141
      8142 |        8143 |        8141
      8142 |        8194 |        8141
      8194 |        8143 |        8141
      8194 |        8142 |        8141
      8194 |        8194 |        8141
(6 rows)


If I unsubscribe the set, the listen path returns...

It may or may not be significant that 8141 is also the origin for a 
third set.  Thought i'd mention it.



JP


-- 
JP Fletcher
Database Administrator
Afilias Canada
voice: 416.646.3304 ext. 4123
fax: 416.646.3305
mobile: 416.561.4763
jpfletch at ca.afilias.info