Greg Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend