Re: Tricky bugs in concurrent index build

Ühel kenal päeval, K, 2006-08-23 kell 09:01, kirjutas Tom Lane:
> 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.

Perhaps we should scan the index in index order, and set the unique flag
per index page.

That would
a) help us avoid going to heap unless there are multiple entries for
some value and
b) enable us, once all index pages containing pointers to some possibly
duplicate value are checked, to release locks on those tuples.

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com