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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
