I wrote:
> The problem case is that we take a tuple and try to insert it into the index.
> Meanwhile someone else updates the tuple, and they're faster than us so
> they get the new version into the index first. Now our aminsert sees a
> conflicting index entry, and as soon as it commits good aminsert will
> raise a uniqueness error. There's no backoff for "oh, the tuple I'm
> inserting stopped being live while I was inserting it".
It's possible that the problem could be solved by introducing such a
backoff, ie, make aminsert recheck liveness of the tuple-to-be-inserted
before declaring error. Since we're about to fail anyway, performance
of this code path probably isn't a huge issue. But I haven't thought
through whether it can be made to work with that addition.
Unless someone's got a brilliant idea, my recommendation at this point
is that we restrict the patch to building only non-unique indexes.
Per discussion upthread, that's still a useful feature. We can revisit
the problem of doing uniqueness checks correctly in some future release,
but time to work on it for 8.2 is running out fast.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
