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."

So it's quite likely that a pg upgrade and / or slony upgrade fixed that.