Re: Tricky bugs in concurrent index build

Greg Stark <gsstark(at)mit(dot)edu> writes:
> Hmmm. Or is that true. The problem may be somewhat easier since at least you
> can be sure every tuple in the heap is in the index. So if you see a
> DELETE_IN_PROGRESS either it *was* a constraint violation prior to the delete
> and failing is reasonable or it's an update in which case maybe it's possible
> to detect that they're part of the same chain?

Unless we are willing to lock every single tuple while we insert it,
this seems unfixable to me. Without a lock, the tuple could become
DELETE_IN_PROGRESS immediately after we look at it.

Actually it's worse than that. We could examine a tuple, see that
it's good, include it in the uniqueness check. Then someone updates
the tuple and puts the new version near the end of the table. By
the time we reach that version, it could be committed good. There
is absolutely no way that we could notice an issue without applying
extremely expensive tests to *every* apparently-good tuple.

[ thinks for a bit... ] At least, it seems hopeless if we use
SnapshotNow. Does it help if we use a real snapshot? I'm thinking
pass 1 inserts exactly those tuples that are good according to a
snap taken at its beginning, and then pass 2 considers only tuples
that are good according to a snap taken at *its* beginning. But
having consumed no caffeine yet this morning, I'm not sure I can
spot any flaws that might exist in this idea.

regards, tom lane