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
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 |