Re: index corruption on composite primary key indexes - Mailing list pgsql-bugs

From Mikael Krantz
Subject Re: index corruption on composite primary key indexes
Date
Msg-id AANLkTimHharM0HCfW-6-nqaC9kbsoTcJo6iWoEL4geqZ@mail.gmail.com
Whole thread Raw
In response to index corruption on composite primary key indexes  ("Ng, Stan" <sng@automotive.com>)
List pgsql-bugs
This could quite possibly be a correct behaviour. "duplicate key value
violates unique constraint" usually happens when you try to insert a
row to a table already containing a row with the same value(s) for the
key column(s). If you have two connections both trying to insert a new
record with the same key, one of them will succeed and the other one
will fail with "duplicate key value violates unique constraint". The
first transaction to commit wins here so it may cause the
unpredictable behaviour you're seeing due to timing variations.

Probably you should catch this error and decide what the proper action
to take is; it might be ignoring the second insert, it might be
updating the already existing row with that key or something else
entirely, depending on your application.

Best Regards

Mikael Krantz

On Tue, Dec 14, 2010 at 3:18 AM, Ng, Stan <sng@automotive.com> wrote:
> I=92ve noticed what appears to be index corruption on composite primary k=
ey
> indexes during my testing. Data deletes, updates, and inserts are applied
> from delta data that is loaded into temporary tables. The duplicate key
> error occurs at different points in time and isn=92t isolated to any sing=
le
> table, although all affected tables have a composite primary key index. F=
or
> example, if machine1 and machine2 both start off from the same starting
> state, then machine1 might fail on delta 100 while machine2 won=92t fail =
until
> delta 125. The error in the log is =93duplicate key value violates unique
> constraint=94 with a reference to the composite primary key index. The is=
sue
> occurs on different machines, so that would seemingly rule out hardware
> failure. The fact that it only happens on tables with composite primary k=
eys
> is highly suspicious. It occurs reproducibly enough that it seems to be a
> pgsql bug, or maybe a pgsql running on a certain set of hardware + softwa=
re.
>
>
>
> Some info on the platform I=92m using:
>
> PostgreSQL 8.4.4
>
> Red Hat 4.1.2-44
>
> Linux 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64
> x86_64 GNU/Linux
>
> Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
>
>
>
> Does anyone know if this a known issue? Any help would be much appreciate=
d.

pgsql-bugs by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: BUG #5776: Unable to create view with parameter in PL/pgsql
Next
From: Pavel Stehule
Date:
Subject: Re: BUG #5776: Unable to create view with parameter in PL/pgsql