Re: Urgent: Key constraints behaving weirdly - Mailing list pgsql-bugs

From Russell Garrett
Subject Re: Urgent: Key constraints behaving weirdly
Date
Msg-id MKEGJINFADFODDNOKEJCGEIDENAA.rg@tcslon.com
Whole thread Raw
In response to Re: Urgent: Key constraints behaving weirdly  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Urgent: Key constraints behaving weirdly  ("Russell Garrett" <rg@tcslon.com>)
List pgsql-bugs
Tom Lane wrote:
> "Russell Garrett" <rg@tcslon.com> writes:
>> Constraints are being weird. The reproduction instructions speak for
>> themselves.
>
> You haven't really provided enough info to let anyone do anything
> about this.  Certainly no one else is going to be able to reproduce
> the problem based on what you've provided.

I'm aware of that, but it's really quite difficult to rule out everything.
Our database isn't that small, and we don't have the resources to
immediately deduce a test case (i.e. it's just me ;).

> I can think of a number of theories:
>
> 1. There's a rule or trigger ON UPDATE that is modifying the behavior
> of the update you showed, and is causing the duplicate-key error (ie,
> there's a bug in the rule or trigger logic and the error report is
> legitimate).

There's nothing triggered by that update.

> 2. The index is corrupt, possibly due to a hardware glitch.  (This
> seems unlikely because the SELECT result appears normal, but I can't
> rule it out entirely.)

We had a table error a few weeks back, however we re-imported the table from
scratch. So it may well be this. I doubt it's a actually a Postgres bug now,
since we aren't doing anything particularly unusual, and it's been working
fine for several weeks. Still, I'm not ruling it out.

Russ

pgsql-bugs by date:

Previous
From: "PostgreSQL Bugs List"
Date:
Subject: BUG #1015: Got a signal 11 while trying to create a temp table
Next
From: "Russell Garrett"
Date:
Subject: Re: Urgent: Key constraints behaving weirdly