On 12/16/2014 05:32 AM, Carlos Henrique Reimer wrote: > "8357_isarq"."wm_bco_pla"; " PGRES_FATAL_ERROR ERROR: could not create > unique index "pk_wm_bco_pla" > DETAIL: Key (bco_cod, pla_cod)=(399, 5056110) is duplicated. > CONTEXT: SQL statement "reindex table "8357_isarq"."wm_bco_pla"" > PL/pgSQL function finishtableaftercopy(integer) line 26 at EXECUTE statement > 2014-12-16 07:08:25 BRST WARN remoteWorkerThread_1: data copy for set > 999 failed 108 times - sleep 60 seconds > > The error indicates "8357_isarq"."wm_bco_pla" has duplicated rows for > primary key (bco_cod, pla_cod)=(399, 5056110) but when I query the > table using this pk I got only one row: > > select * from "8357_isarq"."wm_bco_pla" where bco_cod=399 and pla_cod = > '5056110'; > bco_cod | pla_cod | pla_des | ativo | > conta_pai | pla_itlistserv | pla_ctacosif > ---------+---------+---------------------------------------+-------+-----------+----------------+-------------- > 399 | 5056110 | RENDAS TRANSACOES VISA ELETRON - HBBR | S | > 5056004 | 1501 | 71799003 > (1 row)
This means that a sequential scan (done by the COPY) produces multiple rows with that primary key, while only one of them has an index entry. As Andrew pointed out, you have index corruption on the source database. I bet a REINDEX of that table on the source will fail too. > Slony is trying to merge the temporary set to the main set every 60 > seconds and getting this error. I do not want to loose three days of > replication processing. No, Slony is still processing the SUBSCRIBE SET for the small temporary set (and repeatedly failing on that). The MERGE SET is queued behind and not touched yet. > Is there anything I can do to fix this error or at least can I remove > this table from the temporary set and work on this issue afterwards? Reading your follow up, you only got a single duplicate on this one. However, there is a high chance that your DELETE actually deleted the wrong row version. Since you are running a really outdated version of PostgreSQL I would not be surprised if some bug made an outdated version of that row visible again. The index entry for that PK would be pointing at the last row version, which you now deleted. The replica would now contain the old row version again. Check if you have a row with that PK in the replica and what that actually looks like. Regards, Jan -- Jan Wieck Senior Software Engineer http://slony.info _______________________________________________ Slony1-general mailing list Slony1-general@lists.slony.info http://lists.slony.info/mailman/listinfo/slony1-general
