Re: Duplicate rows sneaking in despite PRIMARY KEY / UNIQUE
От | Travis Cross |
---|---|
Тема | Re: Duplicate rows sneaking in despite PRIMARY KEY / UNIQUE |
Дата | |
Msg-id | 4485B50F.8060506@crosswirecorp.com обсуждение исходный текст |
Ответ на | Re: Duplicate rows sneaking in despite PRIMARY KEY / UNIQUE constraint ("Ian Barwick" <barwick@gmail.com>) |
Список | pgsql-hackers |
Ian Barwick wrote: > 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. That's a good thought, and also a possibility. I tend to distrust RAM inherently. If nothing else seems verifiable as the cause, I may have to take the system down on a Saturday night for a good thorough run through memtest86. Cheers, -- Travis
В списке pgsql-hackers по дате отправления: