Jaime Casanova jcasanov at systemguards.com.ec
Tue Apr 6 12:12:48 PDT 2010
On Tue, Apr 6, 2010 at 9:22 AM, Gordon Shannon
<gordon at collectiveintellect.com> wrote:
> Looks like tab_id 287 used to be tcom_puja_backup, but now is tcom_puja.
>

yeah but that was in september, and i installed slony 2 or 3 weeks ago.
Besides, audit_log.tcom_puja_backup had no pk

> 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.
>

after fixing this i did this to confirm there is no problems with other tables
"""
 select tab_reloid::regclass, tab_reloid, tab_nspname, tab_relname
   from _sncp_incop_cluster.sl_table
 where tab_reloid <> (tab_nspname || '.' || tab_relname)::regclass;
"""

and get no rows, so seems like there is no more problems... but still
want to know what happens first time...

> 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.
>

what i did is to rename an existing index on audit_log.tcom_puja an
create the pk for audit_log.tcom_puja_backup with name of the index i
just free up.

then after that table get copied and successfully subscribed... i
dropped it, fix tha names of indexes on both tables and added them
again in a new set and then merge... seems like everything is working
now

-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157


More information about the Slony1-bugs mailing list