Re: BUG #13935: Duplicate row in pg_constraint table which is not accessible via indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: bear2k(at)mail(dot)ru, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #13935: Duplicate row in pg_constraint table which is not accessible via indexes
Date: 2016-02-10 18:01:38
Message-ID: 30153.1455127298@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> I wonder if you got into this state by adding primary keys concurrently
> somehow. That should of course not be allowed, but of course there is
> no UNIQUE constraint on conrelid itself, so the normal unique-ification
> code in btree does not fire for this situation.

I thought maybe Simon's changes to reduce lock levels in ALTER TABLE
had gone too far, but simple experiment shows that ALTER ADD PRIMARY KEY
commands still block each other (and then the second one fails as
expected). So there isn't an obvious hole here.

Given that the OIDs are different, it seems more likely that this is the
result of a primary key being dropped and then re-created, and later
somehow the commit state of the original row got reverted.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2016-02-10 21:25:36 Re: BUG #13935: Duplicate row in pg_constraint table which is not accessible via indexes
Previous Message Tom Lane 2016-02-10 17:46:05 Re: BUG #13941: Different value "pg_constraint.consrc" for similar Check Constrait