Marc Munro wrote:
> I have been experiencing errors due to pk violations on my slony
> subscriber and could really use some suggestions.
>
> I have tracked it down, using the postgres logs, to the same insert
> statement being issued twice in succession.  The source data for that
> insert only appears once in sl_log_1;
>   
The fact that you only see it once in sl_log_1 tells me that the source
ought to be right.

It could be worth reindexing sl_log_1 on the source node; that would
regrettably block new (replicable) activity there, but would *hopefully*
be quick; if that helped, that would indicate a corruption of the index
on sl_log_1.  (You have tried to rule that out; it's quite possible that
you have done so successfully...)  If sl_log_1 isn't too big, yet, that
could be a quick thing to try; if it repairs the problem, you've gotten
an easy fix :-).

There is another possibility that I don't think you've explored, which
is that of index corruption on the *subscriber*.

That is, that the index on table_trans_attribute is busted on the
subscriber.

You *didn't* do that on the subscriber, I don't think, and it seems more
likely to me to be the root of things...

I believe we've observed this happening; a reindex of the replicated
table *on the subscriber* turned out right.  Happily, that would not
block the "master" in any way.

When that's happened, it has indicated a bug in PostgreSQL.  Possibly
fixed in later releases (we observed the problem with 7.4.x).