On Fri, 2009-11-13 at 21:59 -0700, Scott Marlowe wrote:
> On Fri, Nov 13, 2009 at 3:01 AM, Csaba Nagy <nagy at ecircle-ag.com> wrote:
> > On Thu, 2009-11-12 at 17:26 +0100, Vick Khera wrote:
> >> Do you have triggers on the slave?  Did you alter *any* tables without
> >> using the proper EXECUTE SCRIPT functionality?
> >>
> >> I'll vote that you (or someone else) did.
> >>
> >> Fix: drop the table in question from slony, and re-add it.  For good
> >> measure, run EXECUTE SCRIPT on an empty script to ensure that
> >> everything gets re-set properly, too.
> >
> > Just as additional input: I have seen this with postgres 8.2.4 and slony
> > 1.2.16 too, immediately after the initial sync... there was only one
> > (fairly big, in the 10^10th rows and 100s of GB order of magnitude)
> > table, and it was most definitely not altered. After upgrading to slony
> > 1.2.17 it did work - but maybe the upgrade is not the real problem, but
> > some other race condition in the slony/postgres code.
> 
> According to the Admin Guide to Slony,
> (file:///home/smarlowe/work/slony1-2.0.2/doc/adminguide/maintenance.html)
> :  "The  Duplicate Key Violation bug has helped track down a number of
> rather obscure PostgreSQL race conditions, so that in modern versions
> of Slony-I and PostgreSQL, there should be little to worry about."

That's only partially correct.  

There are strong indications of other manifestation(s) of this issue as
recently as 8.1.11, and we also have a mention of 8.2.4

The last bugs we isolated around this AFAIK where in 7.4 (around 7.4.7
or 7.4.8 if memory serves me) and were fixed. 

-- 
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.