| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | dinesh <dinesh(at)mongonet(dot)net> |
| Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: duplicate key violated errors |
| Date: | 2009-10-26 23:02:20 |
| Message-ID: | 16892.1256598140@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
dinesh <dinesh(at)mongonet(dot)net> writes:
> I have a table, which has over 3 million rows. We have both a unique
> constraint ( which creates implicit index) as well as a regular unique
> index on the same column. We had to put the unique constraint because
> duplicate values
> were getting inserted to the table in spite of the regular unique index
> on the column.
That sounds awfully fishy. We have not heard of unique indexes failing
to enforce the constraint in quite some time.
What's the data type of the column? A possible explanation for this
kind of issue is a broken comparison function for the particular data
type.
> We run postgresql 8.2.5
That's two years out of date, and the list of bugs fixed since then is
quite extensive. A quick scan through the release notes doesn't show
any obviously-related bugs, but it would still be worth your while to
update to 8.2.latest and then reindex to see if the problem goes away.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-10-26 23:07:21 | Re: Warm standby problems |
| Previous Message | Naomi Walker | 2009-10-26 22:57:41 | Re: pg_attribute size |