Looks like tab_id 287 used to be tcom_puja_backup, but now is tcom_puja.

The tab_id's must match on both sides.   The most disturbing question is how did this get this way, and what else is broken?  You might want to DROP SET and resubscribe. 

If that's impractical, then I would shut down all slons, and update the sl_table on the subscriber side to make them match the origin.  Be careful that the tab_reloid's are correct within that node as well as tab_id. Then restart and hope.

Gordon


On Apr 5, 2010, at 11:17 PM, Jaime Casanova wrote:

> Hi,
> 
> I'm starting a replica, i divided it in 3 sets (actually i'm adding a
> new node after upgrading os and pg version)...
> 
> slony version 1.2.20 pg version 8.4.3
> 
> i had no problem with set 1 and set 2 but when replicating set 3, it
> never finish copying tables and when i look for errors in the slave
> postgres log i found this:
> """
> 2010-04-05 00:36:38 GMT [10017]: [4-1] 192.168.1.50(60202) STATEMENT:
> select "_sncp_incop_cluster".setAddTable_int(3, 287,
> '"audit_log"."tcom_puja_backup"', 'tcom_puja_pkey', '');
> 2010-04-05 00:42:36 GMT [10017]: [5-1] 192.168.1.50(60202) ERROR:
> Slony-I: setAddTable_int(): table "audit_log"."tcom_puja_backup" has
> no index tcom_puja_pkey
> """
> 
> but when searching that table on sl_table i get this:
> """
> mic=# select * from _sncp_incop_cluster.sl_table where tab_id =287;
> tab_id | tab_reloid | tab_relname | tab_nspname | tab_set |
> tab_idxname   | tab_altered | tab_comment
> --------+------------+-------------+-------------+---------+----------------+-------------+-------------
>    287 |      21940 | tcom_puja   | audit_log   |       3 |
> tcom_puja_pkey | t           |
> (1 row)
> """
> 
> so, obviously it is trying to replicate the wrong table, if i try to
> fix this mess by dropping the table from replication using "set drop
> table(origin=1, ID = 287 );" i get this:
> """
> <stdin>:3: PGRES_FATAL_ERROR select
> "_sncp_incop_cluster".setDropTable(287);  - ERROR:  Slony-I:
> alterTableRestore(): Table with id 287 not found
> CONTEXT:  SQL statement "SELECT  "_sncp_incop_cluster".alterTableRestore( $1 )"
> PL/pgSQL function "setdroptable_int" line 52 at PERFORM
> SQL statement "SELECT  "_sncp_incop_cluster".setDropTable_int( $1 )"
> PL/pgSQL function "setdroptable" line 40 at PERFORM
> """
> 
> now, the table that is being replicated "doesn't" have a pkey while
> the table that should have been in the replication (and that i put in
> the script) do have a pkey (the pkey that is being assigned by slony
> to the other table)...
> 
> the problem is that somehow the tab_reloid is for that recors is the
> oid of the other table... i can't simply change that because the other
> table has the trigger...
> so, i'm accepting ideas...
> 
> what i'm thinking first is to add the pkey to the table (i will rename
> an existing pkey on the other table and create i new one with this
> name here) but don't know if i have to fix tab_relname
> 
> ideas?
> 
> -- 
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Asesoría y desarrollo de sistemas
> Guayaquil - Ecuador
> Cel. +59387171157
> _______________________________________________
> Slony1-bugs mailing list
> Slony1-bugs at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-bugs