If you rearrange the nodes so that they serve different purposes, this will likely lead to the subscribers changing a bit.
This will require doing several things:
If you want a node that is a subscriber to become the origin for a particular replication set, you will have to issue a suitable slonik(1) MOVE SET operation.
You may subsequently, or instead, wish to modify the subscriptions of other nodes. You might want to modify a node to get its data from a different provider, or to change it to turn forwarding on or off. This can be accomplished by issuing the slonik SUBSCRIBE SET(7) operation with the new subscription information for the node; Slony-I will change the configuration. No need to ask for UNSUBSCRIBE SET(7); no need for it to start copying data from scratch; the SUBSCRIBE SET(7) request will reshape the subscription "on the fly" and allow data to remain consistent between nodes.
If the directions of data flows have changed, it is doubtless appropriate to issue a set of DROP LISTEN(7) operations to drop out obsolete paths between nodes and STORE LISTEN(7) to add the new ones. Up until version 1.1, this was not changed automatically; as of 1.1, MOVE SET(7) and SUBSCRIBE SET(7) change the paths as a side-effect. See Section 9 for more information about this. In version 1.1 and later, generation of sl_listen entries is entirely automated, so that they are regenerated when changes are made to sl_path or sl_subscribe, thereby making it unnecessary to even think about STORE LISTEN(7).
After performing the configuration change, you should, as Section 2, run the Section 5.1 scripts in order to validate that the cluster state remains in good order after this change.
The altperl toolset includes a regenerate-listens script that is up to the task of creating the new STORE LISTEN(7) commands; it isn't, however, smart enough to know what listener paths should be dropped.