I have a "followup question" concerning #1485...

When you ran into problems with your five node example shaped like...

       1  -->  10 --> 11
           -->  20 --> 21

(e.g. - 1 feeds 10 and 20, then 10 feeds 11, 20 feeds 21, and we have
paths exactly corresponding to 2-way communications there...)

It's not entirely clear what your path/listener configuration looked like.

>From what I can see, it should look like the following:

/* cbbrowne@[local]/dba2 slonyregress1=*/ select * from
_slony_regress1.sl_path  order by pa_server, pa_client;
 pa_server | pa_client | pa_conninfo | pa_connretry
-----------+-----------+-------------+--------------
         1 |        10 |             |            
         1 |        20 |             |            
        10 |         1 |             |            
        10 |        11 |             |            
        11 |        10 |             |            
        20 |         1 |             |            
        20 |        21 |             |            
        21 |        20 |             |            
(8 rows)

(Obviously, there would be more useful DSN values in a real system ;-).)

Based on the above, and no subscription information, the current,
production listen path builder builds the following:

/* cbbrowne@[local]/dba2 slonyregress1=*/ select li_origin, li_receiver,
li_provider from _slony_regress1.sl_listen order by li_origin,
li_receiver, li_provider;
 li_origin | li_receiver | li_provider
-----------+-------------+-------------
         1 |          10 |           1
         1 |          11 |          10
         1 |          20 |           1
         1 |          21 |          20
        10 |           1 |          10
        10 |          11 |          10
        10 |          20 |           1
        10 |          20 |          21
        10 |          21 |          20
        11 |           1 |          10
        11 |           1 |          20
        11 |          10 |          11
        11 |          20 |           1
        11 |          20 |          21
        11 |          21 |          20
        20 |           1 |          20
        20 |          10 |           1
        20 |          10 |          11
        20 |          11 |          10
        20 |          21 |          20
        21 |           1 |          10
        21 |           1 |          20
        21 |          10 |           1
        21 |          10 |          11
        21 |          11 |          10
        21 |          20 |          21
(26 rows)

If I define the set and subscriptions as described:

/* cbbrowne@[local]/dba2 slonyregress1=*/ select * from
_slony_regress1.sl_set;
 set_id | set_origin | set_locked | set_comment
--------+------------+------------+-------------
      1 |          1 |            |
(1 row)

/* cbbrowne@[local]/dba2 slonyregress1=*/ select * from
_slony_regress1.sl_subscribe ;
 sub_set | sub_provider | sub_receiver | sub_forward | sub_active
---------+--------------+--------------+-------------+------------
       1 |            1 |           10 |             |
       1 |            1 |           20 |             |
       1 |           10 |           11 |             |
(3 rows)

 li_origin | li_receiver | li_provider
-----------+-------------+-------------
         1 |          10 |           1
         1 |          11 |          10
         1 |          20 |           1
         1 |          21 |          20
        10 |           1 |          10
        10 |          11 |          10
        10 |          20 |           1
        10 |          21 |          20
        11 |           1 |          10
        11 |           1 |          20
        11 |          10 |          11
        11 |          20 |           1
        11 |          21 |          20
        20 |           1 |          20
        20 |          10 |           1
        20 |          10 |          11
        20 |          11 |          10
        20 |          21 |          20
        21 |           1 |          10
        21 |           1 |          20
        21 |          10 |           1
        21

The difference is these two listener entries, which, analytically, it
makes sense can be dropped without adversely affecting the cluster.  (If
you think about it, node 21 is a *crummy* node for node 20 to use as a
provider for events from node 10, and ditto for 21 as a provider to 20
for events from node 11.)

 li_origin | li_provider | li_receiver
-----------+-------------+-------------
        10 |          21 |          20
        11 |          21 |          20
(2 rows)

Would it be possible for you to provide a more exact list of what the
(apparently wrong) listen network looked like?  I don't see the existing
calculation breaking down, in this case.

Attached is a gzipped listing of my results so far; I took the material
in bug #1485 and rewrote the examples to look as they should in the
actual Slony-I schema.

By the way, the algorithm that you propose seems only to differ in one
material way from the existing one:  The existing one will prefer more
direct listen paths based on sl_subscribe to those of "lesser" status. 
That is what led to the 2 row difference above.  That difference
shouldn't cause the problem you observed, in that all it does is to
eliminate some paths that wouldn't have been useful anyways.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testlisten.txt.gz
Type: application/gzip
Size: 925 bytes
Desc: not available
Url : http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060228/8696ffd2/testlisten.txt.bin