Re: Duplicate rows sneaking in despite PRIMARY KEY / UNIQUE constraint - Mailing list pgsql-hackers

From Ian Barwick
Subject Re: Duplicate rows sneaking in despite PRIMARY KEY / UNIQUE constraint
Date
Msg-id 1d581afe0606060758m8b61ef6mafdc91dcf1bda0b@mail.gmail.com
Whole thread Raw
In response to Re: Duplicate rows sneaking in despite PRIMARY KEY / UNIQUE constraint  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Duplicate rows sneaking in despite PRIMARY KEY / UNIQUE  (Travis Cross <travis@crosswirecorp.com>)
List pgsql-hackers
On 6/6/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Travis Cross <travis@crosswirecorp.com> writes:
> > I'm noticing that a handful (4-16) of rows with duplicate columns
> > (uid,token) are sneaking into the table every day despite the
> > primary key constraint.
>
> Corrupt index, looks like ... you might try reindexing the index.
>
> I don't believe that the PANIC you show has anything directly to do
> with duplicate entries.  It is a symptom of corrupt index structure.
> Now a corrupt index might also explain failure to notice duplications,
> but changing your application isn't going to fix whatever is causing
> it.  You need to look for server-side causes.
>
> Any database or system crashes on this server (before this problem
> started)?  Do you *know* that the disk drive will not lie about write
> complete?  What is the platform and storage system, anyway?

FWIW I've seen similar behaviour to this (PostgreSQL processes exiting
"abnormally", index corruption with duplicate primary keys) on servers
with defective RAM chips.

Ian Barwick


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: COPY (query) TO file
Next
From: Simon Riggs
Date:
Subject: Re: fillfactor using WITH syntax