Re: Tricky bugs in concurrent index build

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> What I think we can do about this is to include DELETE_IN_PROGRESS
> tuples in the set of candidate tuples to insert in the second pass.
> During the merge step that verifies whether the tuple is already
> in the index, if we find that it's not, then we must wait for the
> deleter to commit or roll back. If the deleter commits then we
> ignore the tuple. If the deleter rolls back then we have to insert
> the tuple in the index. (I think we have to actually take a FOR
> UPDATE or possibly FOR SHARE lock on the tuple while we do this,
> else we have race conditions against someone else starting a new
> deletion attempt on the tuple.)

Hm, my first thought was to just try to get a lock on the record which would
inherently wait until the deleter commits or aborts.

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?

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.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com