"Mason Hale" <masonhale@gmail.com> writes:
>> For that matter, do you still see dups if you prevent use of the index
>> in the 8.2.5 query? Maybe it's that index that is corrupt.
> Unfortunately, I'm not able to test that at this point.
> To get our production db (the 8.2.5 instance) back in operation I deleted
> the extra duplicate rows, so that the update statement would complete.
Mph. I'm afraid the evidence is mostly gone then, and we probably won't
be able to figure out what happened. However, it would be worth
checking two things:
1. Can you confirm that the rows that got duplicated were in fact
present (in only one copy) in the 8.2.4 DB?
2. Can you check that there are still 1 (rather than 0) copies of the
rows in the 8.2.5 DB? One possible theory about this is that what you
had was (two instances of) two index entries pointing at the same heap
row, in which case a DELETE that you thought removed only one copy would
have deleted both.
regards, tom lane