Re: Duplicate rows sneaking in despite PRIMARY KEY / UNIQUE constraint

From: "Ian Barwick" <barwick(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Travis Cross" <travis(at)crosswirecorp(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Duplicate rows sneaking in despite PRIMARY KEY / UNIQUE constraint
Date: 2006-06-06 14:58:38
Message-ID: 1d581afe0606060758m8b61ef6mafdc91dcf1bda0b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/6/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Travis Cross <travis(at)crosswirecorp(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2006-06-06 15:00:36 Re: fillfactor using WITH syntax
Previous Message Jim C. Nasby 2006-06-06 14:56:17 Re: COPY (query) TO file