Christopher Browne said:

> No, the "expected result" of submitting "that command" to a node
> already participating in a subscription is for the subscription
> provider to be revised.
>
> Thus, you might start with...
>
>     A ---> B ----> C
>
> And revise it to...
>
>     A ---> B
>       \
>        \
>         \> C
>
> If you request a 'path' that is already in effect, it'll turn out as a
> NOOP.
>
> What you could do to accomplish what I think you want to do is to
> submit "*UN*S*U*B****** SET."

I just gave this a try.  I rebuilt my cluster from scratch and had a 2
machine cluster.  I issued:

unsub*scr*ibe set (id = @SET_FULL, receiver = @NODE_02);

This seemed to work as documented.  The database on the slave was
unlocked, so I could modify it, and the slony-added schema remained in
place.

I then issued:

sub*scr*ibe set (id = @SET_FULL, provider = @ORIGIN, receiver = @NODE_02,
forward = no );

That didn't seem to do anything.  The database remained unlocked and I
didn't see any copy activity in the slon log that services that node.

I then decided to add a third node to the cluster.  I issued:

store node (id=@NODE_04, comment = 'Node 04 Hartford', spoolnode=false,
event node = @ORIGIN);

This created the schema on that node correctly.  I then started a slon to
service this new node and issued:

sub*sc*ribe set ( id = @SET_FULL, provider = @ORIGIN, receiver = @NODE_04,
forward = no);

Again, nothing.  No copy activity.

Oh, I created the store paths when I created the cluster originally.

Did I miss something or is there a problem with sub*scr*ibing sets on an
existing cluster?