Is it possible someone made a manual change to the slave?  If so, that
could definitely lead to a duplicate key error.

I know that to do that you'd have to first manually remove the trigger
that's there to keep you from making manual changes.  Just throwing out
ideas...

--S


-----Original Message-----
From: slony1-general-bounces at lists.slony.info
[mailto:slony1-general-bounces at lists.slony.info] On Behalf Of Jan Wieck
Sent: Tuesday, August 19, 2008 8:03 AM
To: Thomas Spreng
Cc: slony1-general at lists.slony.info
Subject: Re: [Slony1-general] Random Duplicates Error

On 8/19/2008 5:41 AM, Thomas Spreng wrote:
> hi everyone,
> 
> I have a problem with one of our current slony clusters.
> The cluster consists of one origin and 3 subscribers all running  
> Slony1 v.1.2.14 and PostgreSQL v.8.3.3 on Debian Etch.
> There are around 3 mil. rows in one big table that are deleted and  
> newly inserted on a daily basis.

When that error occurs, slony would retry over and over again. In that 
case, is it failing on the exact same key value over and over, or is the

key value changing?

Does reindexing the sl_log_1 and sl_log_2 tables on the data provider 
for the failed node eventually help? If so, something on that data 
provider causes index corruption. We know of one Postgres bug that was 
supposedly fixed some time ago that caused this symptom, so Postgres 
itself being at fault is not out of the question.


Jan


> 
> Every now and then (around once a week) one (any of them) of the  
> subscribers fails to replicate the origin's data with the following  
> message in the log:
> ERROR:  duplicate key value violates unique constraint "xyz"
> 
> There is no further indication in the logs what could have been the  
> cause for this problem.
> 
> 1) is this a known problem that the replication may fail occasionally

> when there are lots of insert's going on? Any suggestions on what I  
> could do to prevent this from happening?
> 2) what's the preferred workaround for such a situation? right, now  
> I'm just dropping the corresponding node and re-create it from
scratch.
> 
> cheers,
> 
> tom.
> 
> 
> PS: other clusters on the same hosts don't never have such problems  
> but they also don't have that many deletes/inserts going on.
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general


-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

_______________________________________________
Slony1-general mailing list
Slony1-general at lists.slony.info
http://lists.slony.info/mailman/listinfo/slony1-general