Re: Tricky bugs in concurrent index build

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I think that's OK, but the whole idea of using an MVCC snap in phase 2
>> doesn't work on closer inspection. The problem is still the same one
>> that you need to take (at least) share lock on each tuple you insert
>> into the index. Telling aminsert to check uniqueness implicitly assumes
>> the new tuple is live, and without any lock on the tuple you can't
>> promise that.

> No wait. It's still "live" according to my snapshot. How could it be possible
> for a single snapshot to see two different versions of the same tuple as live?

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".

regards, tom lane