Tom Lane wrote:
> Maybe there actually is a duplicate key in the source DB --- have you
> checked? There were some bugs in early 8.2.x releases that could
> possibly allow that to happen.
Thanks, I was hoping there would be an easy explanation like that. I guess I'll
have to do a little reading
Quick update: Seems like removing that tuple has solved the issue, dump and
import of that table went fine, everything is where is should be - but there
shouldn't have been an issue there in the first place however, with the primary
key constraint present in the source database. I'm still curiou
"Markus Wollny" <[EMAIL PROTECTED]> writes:
> I'm currently trying to migrate one of our databases from PostgreSQL 8.2.4 to
> PostgreSQL 8.3.1. I have worked around the Tsearch2 migration (we used the
> contrib module) without too much hassle, but find myself stuck at an
> unexpected point - I g
"Blair Bethwaite" <[EMAIL PROTECTED]> writes:
> Why would we be getting a duplicate key violation on the primary key
> of this table when we aren't doing anything in the UPDATE (that I can
> tell) to change it?
Corrupted index, perhaps? Can you REINDEX that table?
There are at least two known bu
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Brian Wipf
>Sent: donderdag 25 januari 2007 22:42
>To: pgsql-general@postgresql.org
>Subject: [GENERAL] Duplicate key violation
>
>I got a duplicate key violation when the following query was performed:
>
@postgresql.org
Subject: Re: [GENERAL] Duplicate key violation
Brian Wipf <[EMAIL PROTECTED]> writes:
> I got a duplicate key violation when the following query was
performed:
> INSERT INTO category_product_visible (category_id, product_id)
> SELECT
Brian Wipf <[EMAIL PROTECTED]> writes:
> I got a duplicate key violation when the following query was performed:
> INSERT INTO category_product_visible (category_id, product_id)
> SELECT cp.category_id, cp.product_id
> FROMcategory_product cp
> WHERE
