Re: Tricky bugs in concurrent index build

Greg Stark <gsstark(at)mit(dot)edu> writes:
> But then wouldn't we have deadlock risks? If we come across these records in a
> different order from someone else (possibly even the deleter) who also wants
> to lock them? Or would it be safe to lock and release them one by one so we
> only every hold one lock at a time?

AFAICS we could release the lock as soon as we've inserted the index
entry. (Whether there is any infrastructure to do that is another
question...)

> I'm also pondering whether it might be worth saving up all the
> DELETE_IN_PROGRESS tuples in a second tuplesort and processing them all in a
> third phase. That seems like it would reduce the amount of waiting that might
> be involved. The fear I have though is that this third phase could become
> quite large.

Actually --- a tuple that is live when we do the "second pass" scan
could well be DELETE_IN_PROGRESS (or even RECENTLY_DEAD) by the time we
do the merge and discover that it hasn't got an index entry. So offhand
I'm thinking that we *must* take a tuple lock on *every* tuple we insert
in stage two. Ugh.

regards, tom lane