Thanks Scott and Tom. Yes. I know, I know that I need to upgrade :-) What would be the newer version of pgsql (I mean a bit higher version of my current version) that provides that capability of telling me what the duplicated key was ? Migration is always a challenge, especially I'm not sure if I will have any unexpected hiccups when I dump my whole DB. I also need to upgrade the OS. My first priority is to get this problem fixed so that my users will stop IM, email or call me. Mary -----Original Message----- From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx] Sent: Wednesday, February 03, 2010 2:21 PM To: Scott Marlowe Cc: Wang, Mary Y; pgsql-general@xxxxxxxxxxxxxx Subject: Re: PQendcopy:resetting connection Problem and Cannot insert a duplicate key into unique index Scott Marlowe <scott.marlowe@xxxxxxxxx> writes: > On Wed, Feb 3, 2010 at 2:16 PM, Wang, Mary Y <mary.y.wang@xxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
