> Hi again ;)
>
> now I've got the following situation
>
> I did some subscription changes (slony 1.0.2, pg 7.4.5) and now I have
> nodes 1 and 5 both subscribing to master node 2
>
> the replication is happening, but both 1 and 5 ended up with subscription
> option forward = yes
>
> userdb=# select * from _userdb_cluster.sl_subscribe ;
>  sub_set | sub_provider | sub_receiver | sub_forward | sub_active
> ---------+--------------+--------------+-------------+------------
>        1 |            2 |            5 | t           | t
>        1 |            2 |            1 | t           | t
> (2 rows)
>
> resulting in sl_log_1 with ~3M rows

Ok Now I was at leas able to convince slony to drop node5 , but I still have
sl_log_1 file of 3.3M rows.

This manifests itself as periods of tens of seconds when the system halts
to a crawl as slony vacuums that big table and clients timeout. The
selects form sl_log_1 are slow as well, but at least they do not affect
other operations ;(

My current solution is to stop slony on slaves during peak periods, but
what I really would like is that the sl_log_1 could be trimmed down.

Other than this the replica is running fine.

------------
Hannu