From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mason Hale" <masonhale(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #3724: Duplicate values added to table despite unique index |
Date: | 2007-11-06 18:06:30 |
Message-ID: | 24142.1194372390@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Mason Hale" <masonhale(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tobias Klausmann | 2007-11-06 18:17:26 | Re: Test suite fails on alpha architecture |
Previous Message | Tom Lane | 2007-11-06 17:57:01 | Re: BUG #3725: plsql does not report unknown functions at compile time |