From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | "Wang, Mary Y" <mary(dot)y(dot)wang(at)boeing(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PQendcopy:resetting connection Problem and Cannot insert a duplicate key into unique index |
Date: | 2010-02-03 22:21:01 |
Message-ID: | 7458.1265235661@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> writes:
> On Wed, Feb 3, 2010 at 2:16 PM, Wang, Mary Y <mary(dot)y(dot)wang(at)boeing(dot)com> wrote:
>> I still couldn't find that particular line that caused that problem :-(. Counting was very pain.
>> Is there anyway that I can tell psql just to "ignore" (I mean don't insert it duplicate key into unique index users_pkey) and just keep going without doing the PQendcopy:resetting connection?
> Not really directly. What I'd do is remove the unique constraint,
> insert, then use something like
> select max(row_id) from table t1 join table t2 on
> t1.somefield=t2.somefield and t1.row_id<>r2.row_id;
> to find dupes and remove them.
> Then I'd dump the whole db and migrate to a more modern version of pgsql.
If you were using a more modern version of pgsql, it would tell you what
the duplicated key was ;-). So maybe you could try loading the dump
file into something newer as a means of debugging the problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Wang, Mary Y | 2010-02-03 22:31:42 | Re: PQendcopy:resetting connection Problem and Cannot insert a duplicate key into unique index |
Previous Message | Tim Landscheidt | 2010-02-03 22:07:22 | Re: JOIN Record returning Function |