Re: Tricky bugs in concurrent index build

stark <stark(at)enterprisedb(dot)com> writes:
> What happens if someone inserts a record that we miss, but it gets deleted by
> the same phase 2 starts. So it's not visible to phase 2 but conflicts with
> some other record we find. I suppose that's ok since the delete would have to
> have comitted for that to happen.

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. So there's a significant risk of falsely declaring a
uniqueness failure due to someone else's perfectly innocent UPDATE.
Using an MVCC snap would actually make this worse, by widening the
window for that UPDATE to happen.

Even though we're hoping not to have to process too many tuples here,
having to row-lock each one sounds pretty awful. Remember that that
involves writing a WAL record these days.

regards, tom lane