Does anyone have any idea about this?

> > How do I remove this set from the subscriber?
> 
> I think it's somehow scheduled up behind whatever that thing
>going
> for 
> node -1 is looking. If you can get rid of that one from
>sl_listen,
> I bet 
> the set dropping will go through.
> 
> 
 
There doesn't seem to be a -1 node in the sl_listen on the origin
or the subscriber.
 
I've removed the second set that was still visible on the subscriber
from the sl_set table, however I'm still getting an event in the log
where it tries to "copy_set 2" and comes back with the error "set 2
not found in runtime configuration".
 
Any idea on how I remove / stop this?
 
> > I've had this happen before. Removing the cluster and setting
>it
> up
> > again resolves the problem, however once we are in a production
> > environment I can't go dropping the whole cluster and
>replicating
> all
> > the tables from scratch when it happens.
> 
> Can you give us an exact step-by-step on how to make it happen?
> 

I tried to subscribe a new set with a new table in it and for some
reason it failed with the error mentioned. The slony logs show that
slony was periodically trying to subscribe on the subscriber.

Seeing as I couldn't remove it from pgAdmin, I went in and ran a
slonik script to drop the set, however I didn't try to unsubscribe
it
with slonik first. So is there a chance it's come about from me not
unsubscribing first?

What's the law on mixing the use of pgAdmin and slonik to
administer slony?



      ___________________________________________________________
Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/