Alvaro Herrera <alvherre@2ndquadrant.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
