Hi Jan,

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.

Tried a reindex table and it worked fine.

Hope no more discrepancies will be found until the complete cluster is
replicated.

Thanks!


On Tue, Dec 16, 2014 at 3:56 PM, Jan Wieck <jan at wi3ck.info> wrote:
>
> 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
>


-- 
Reimer
47-3347-1724 47-9183-0547 msn: carlos.reimer at opendb.com.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20141216/ec3f055b/attachment.htm