Re: Serializable Isolation without blocking

2010/1/7 Markus Wanner <markus(at)bluegap(dot)ch>:

> (It's interesting that with "database page" level granularity, he states
> that predicate locking would not be necessary. Instead any page can be
> locked at any time. For this to work, according to my reasoning, you'd
> have to know in advance on which page potentially accessible (but not
> yet visible) new tuples would end up. This is close to impossible for
> Postgres, however, it seems to work for Berkeley DB).

The specifics of relation databases can be entirely ignored in case
serializability is provided on the "page layer" level. This also
implies that pages that are part of indexes and such must be treated
in exactly the same way as the pages that constitute the heap.
"Predicate locking" is only needed to provide the same semantics in a
context where the page layer doesn't provide serializability, but
other layers (that understand that we are talking about a relational
database) are supposed to provide it.

I am not suggesting that Postgres should start supporting page layer
level concurrency control, but rather indicating that most literature
should be interpreted this way: concurrency control can be viewed as
orthogonal to relational databases, so that is the way it was
originally modeled.

> As this seems to be an optimization of predicate locking, don't we need
> to implement that first?

Whole-table locking is a trivial implementation of predicate locking.

Nicolas