Re: Violation of primary key constraint

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Toby Murray <toby(dot)murray(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Violation of primary key constraint
Date: 2013-02-01 23:32:44
Message-ID: 26306.1359761564@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Toby Murray <toby(dot)murray(at)gmail(dot)com> writes:
> On Fri, Feb 1, 2013 at 3:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It's conceivable that this was a software glitch not a hardware glitch,
>> ie Postgres forgetting the dirty-bits for a batch of pages, but we've
>> not seen any similar reports elsewhere. So I'm leaning to the hardware
>> explanation.

> Roger that. Unless there is anything else to look at with the database
> in its current state, I will try to delete the duplicates and then
> backtrack my OSM replication process back to the 28th so that any
> other errors that may have gotten in during the botched write are
> redone.

I wish I could think of something else to look at, but right now
I can't. You might as well revert the database. I'd suggest REINDEXing
all the indexes too, since the theory of some dropped page updates would
imply that the indexes are probably not in sync.

It might be worth cranking up logging (eg log_statement = all),
so that if this does happen again, we'll have more to go on.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message mike 2013-02-02 15:28:29 BUG #7846: Documentation: Should FOUND be documented as an output of UPDATE statement?
Previous Message Toby Murray 2013-02-01 23:18:16 Re: Violation of primary key constraint