--- On Wed, 21/4/10, Jaime Casanova <jcasanov at systemguards.com.ec> wrote:

> A customer of mine has the tendency of not follow
> instructions :(
> Recently i found that a table that is audited with
> table_log was
> modified without considering the log table (so the log
> table wasn't
> writing and neither the audited one), to fix that i drop
> the log table
> from the replication, renamed it and create a new one with
> the missing
> column...
> 
> then i tried to readd it to the replication i tried with
> the same id
> number it had before but when i subscribe the set get an
> error on the
> receiver that that tab_id exists so i tried it with a new
> number
> """
> 2010-04-21 00:28:59 ECT DEBUG3 remoteWorkerThread_1: table
> "audit_log"."tcom_control_actividad_fecha" does not require
> Slony-I
> serial key
> 2010-04-21 00:28:59 ECT ERROR  remoteWorkerThread_1:
> "select
> "_sncp_incop_cluster".setAddTable_int(999, 259,
> '"audit_log"."tcom_control_actividad_fecha"',
> 'tcom_control_actividad_fecha_pkey', ''); "
> PGRES_FATAL_ERROR ERROR:
> Slony-I: setAddTable_int: table id 259 has already been
> assigned!
> """
> 
> so i unsubscribe the set, drop the table from the replica,
> and re add
> it again with a new tab_id... but when i try  to
> subscribe it doesn't
> get subscribed and the table doesn't copy and i get this
> error on the
> receiver
> """
> 2010-04-21 01:01:55 ECT DEBUG2 remoteListenThread_1: queue
> event
> 1,819616 SUBSCRIBE_SET
> 2010-04-21 01:01:55 ECT DEBUG2 remoteListenThread_1: queue
> event
> 1,819617 ENABLE_SUBSCRIPTION
> 2010-04-21 01:01:59 ECT DEBUG1 copy_set 999
> 2010-04-21 01:01:59 ECT ERROR  remoteWorkerThread_1:
> node -1 not found
> in runtime configuration
> 2010-04-21 01:01:59 ECT
> WARN   remoteWorkerThread_1: data copy for
> set
> 999 failed 539 times - sleep 60 seconds
> """
> 
> now, i'm getting this message every often... ideas?
> 

I had that "node -1 not found" error a few years ago when I was testing and nobody seemed to be able to say what it means or could be. It would be really interesting if anyone can explain.

For me it happened after a similar sequence of events, where I'd messed up a table, or been dumb and just dropped it without telling first dropping it from slony.  Except that I'm sure dropping the set and re-adding it fixed the issue.

My memory is foggy, but at the time I came to the conclusion that I might also have done something stupid due to pgAdmin not being fully aware of what slony was doing in the background (in this case waiting between subscribe and merge set), and decided to stick with raw slonik.

Still really interested in the node -1 error.