Tom Lane wrote:
> Philip suggested to me off-list that the initial error may have been the
> VACUUM FULL (xid 32902872) creating duplicate moved copies of a single
> valid row. That seems plausible because VACUUM FULL suppresses
> duplicate-index checks, and it's real hard to see any other way that a
> single transaction could have inserted all of these tuples without
> triggering the btree duplicate-key check (barring a completely corrupt
> index anyway).
Another interesting factor -- these problems have not yet happened on
any replicated DB. Slony replication works by using a trigger to store
data changes in a log table; these changes are then applied on the
destination DB. Slony also disables triggers on the destination. Because
of the update load we also run the same vacuum regime.
This seems to make it unlikely that vacuum is the sole culprit.
Another difference is that the replicated DB is only ever updated.
Virtually no load from applications reading data. I wonder if shared
buffers in some way also interact here.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
