2010/1/7 Markus Wanner <mar...@bluegap.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers