Glyn Astill wrote:
> Hi chaps,
>
> I've noticed a problem as described below with regards to adding
> replication
> sets from within pgAdmin. I originally posted on the slony I general
> list,
> and Christopher Browne suggested I ask you guys.
>
> I set up a replication cluster using the pgAdmin scripts, and added a
> replication set with some tables and sequences in it (table /sequence
> Ids 1 - 4). I've kept the Id numbers the same as the table Ids.
>
> Then I added another set (Id 2), and added a table and a sequence
> with Id 5.
>
> In my slony log I get the error:
>
> "remoteWorkerThread_1: node -1 not found in runtime configuration"
>
> Does anyone know what causes the error above? I've read that it
> indicates slony had a problem at a point whilst subscribing so it
> flipped the node number to -1 to stop any further steps happening,
> however this doesn't help me track down what caused it.
Hm. Never seen that one.
> No "drop set" option seems to exist from with pgAdmin (although I'm
> pretty sure I saw it once - are their criteria that make it appear?),
You can only drop a set if it has no subscribers. You have to drop the
subscriber first. Could that be your problem here?
> so I did a "DROP SET ( ID=2, ORIGIN=1 );" using slonik on the origin,
> and
> the set was removed from the origin, but it's still visible
> (using pgadmin) on the subscriber (I have restarted the slons).
> I notice this error occours periodically now in the slony
> logs, so it seems the subscriber is trying to subscribe it? E.g.
>
> ------------------------------------------------------
>
> 2008-01-15_144529 GMT DEBUG2 syncThread: new sl_action_seq 1 - SYNC
> 38491
> 2008-01-15_144533 GMT DEBUG1 copy_set 2
> 2008-01-15_144533 GMT ERROR remoteWorkerThread_1: node -1 not found
> in runtime configuration
> 2008-01-15_144533 GMT WARN remoteWorkerThread_1: data copy for set
> 2 failed - sleep 60 seconds
> WARNING: there is no transaction in progress
>
> ------------------------------------------------------
>
> 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.
> 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?
//Magnus
