Re: A third lock method

"Albe Laurenz"  wrote:
> But with "snapshot isolation" (what our "serializable" corresponds
> to) you cannot see rows updated after snapshot creation, right?
> 
> So phantom reads cannot occur, but we still are not truly
> serializable.
My previous reply missed your point entirely, didn't it?
Let me try again.
You are absolutely right that the phantom phantom rows can't pop up
during a transaction running at snapshot isolation level.  So the
"phantom read" problem, per se, is not an issue.
The problem with phantoms rows in snapshot isolation is not that they
pop up within a concurrent transaction, but that a concurrent
transaction does not block on trying to read them (as they would with
an S2PL serializable implementation) but will just miss them, even
though they might later be (or might already be) committed ahead of
the current transaction.  They need to be considered in the SSI
read-write dependency checks.
Perhaps the affect of such inserts (or updates into a selected range)
manifest is a different enough way that a new term is merited, but
I'm inclined to think not.  The conditions in which they become an
issue are the same.  The techniques for detecting them are the same.
These phantoms just appear to the current connection upon commit of
its transaction rather than in the middle of it, but either way they
cause problems if the current transaction is modifying data based on
its view of them.
-Kevin