<div dir="ltr"><div><div><div><div>Hi Jan,<br><br></div>Just verified the row again and I see it is visible again even after removing it with DELETE this morning. Checked the replica and the table contains the same row with same contents.<br><br></div>Tried a reindex table and it worked fine.<br><br></div>Hope no more discrepancies will be found until the complete cluster is replicated.<br><br></div>Thanks!<br><div><div><div> <br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 16, 2014 at 3:56 PM, Jan Wieck <span dir="ltr"><<a href="mailto:jan@wi3ck.info" target="_blank">jan@wi3ck.info</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/16/2014 05:32 AM, Carlos Henrique Reimer wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"8357_isarq"."wm_bco_pla"; " PGRES_FATAL_ERROR ERROR: could not create<br>
unique index "pk_wm_bco_pla"<br>
DETAIL: Key (bco_cod, pla_cod)=(399, 5056110) is duplicated.<br>
CONTEXT: SQL statement "reindex table "8357_isarq"."wm_bco_pla""<br>
PL/pgSQL function finishtableaftercopy(integer) line 26 at EXECUTE statement<br>
2014-12-16 07:08:25 BRST WARN remoteWorkerThread_1: data copy for set<br>
999 failed 108 times - sleep 60 seconds<br>
<br>
The error indicates "8357_isarq"."wm_bco_pla" has duplicated rows for<br>
primary key (bco_cod, pla_cod)=(399, 5056110) but when I query the<br>
table using this pk I got only one row:<br>
<br>
select * from "8357_isarq"."wm_bco_pla" where bco_cod=399 and pla_cod =<br>
'5056110';<br>
bco_cod | pla_cod | pla_des | ativo |<br>
conta_pai | pla_itlistserv | pla_ctacosif<br>
---------+---------+----------<u></u>-----------------------------+<u></u>-------+-----------+----------<u></u>------+--------------<br>
399 | 5056110 | RENDAS TRANSACOES VISA ELETRON - HBBR | S |<br>
5056004 | 1501 | 71799003<br>
(1 row)<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Slony is trying to merge the temporary set to the main set every 60<br>
seconds and getting this error. I do not want to loose three days of<br>
replication processing.<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is there anything I can do to fix this error or at least can I remove<br>
this table from the temporary set and work on this issue afterwards?<br>
</blockquote>
<br></span>
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.<br>
<br>
Check if you have a row with that PK in the replica and what that actually looks like.<br>
<br>
<br>
Regards, Jan<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-- <br>
Jan Wieck<br>
Senior Software Engineer<br>
<a href="http://slony.info" target="_blank">http://slony.info</a><br>
</font></span></blockquote></div><br clear="all"><br>-- <br><div class="gmail_signature">Reimer<br>47-3347-1724 47-9183-0547 msn: <a href="mailto:carlos.reimer@opendb.com.br">carlos.reimer@opendb.com.br</a><br></div>
</div>