This is going to sound very very odd and highly improbable.  We've had  
a long time intermittent issue where a slave will get a primary key  
violation on a replicated table.   Sometimes we go a few weeks without  
it occurring, sometimes a few hours. Until now I hadn't been motivated  
enough to really dig in (as it often liked to do so at inopportune  
times).  This has happened under PG 8.2 and 8.4 (we're currently on  
8.4, both origin & slave) and on various slony1 versions (we're  
currently on 1.2.17).

The code which is causing the problem is a plpgsql function fired from  
a trigger.
It basically does:
begin;
	delete from thetable where id = v_id;
	insert into thetable (id, otherjunk) values (v_id, v_otherjunk);
end;

"thetable" has a pk on the id column.

Now, for the evidence - this is pulled from sl_log_2 and while I can't  
include log_cmddata here, here is the rest:

   log_xid   | log_actionseq | log_cmdtype
------------+---------------+-------------
  1153890130 |    2800679119 | I
  1153890130 |    2800679120 | D
  1153890760 |    2800716473 | D
  1153890760 |    2800716474 | I
  1153919695 |    2800872885 | D
  1153919695 |    2800880852 | I

Notice in the first txn we insert then delete, then in a later one we  
delete then insert (twice actually).
I was just thinking "what if 2 of them executed at the same time for  
the same id?" but look at the xid - same txn, so there goes that theory.

I looked at the log trigger source and it is assigning actionseq  
through a nextval so I'm at a complete loss as to how this could  
possibly happen.  It does not happen often, and tends to only happen  
on this one table (It may have done so on other tables in the past)  
and we use the delete; insert; pattern in numerous other places  
without issue.  It does not happen all the time - and since it only  
happens on the slave it worked ok and in the proper order on the origin.

Any ideas or are you as baffled as I?

So far, I cannot reproduce this on-demand.

--
Jeff Trout <jeff at jefftrout.com>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/