>>> "Robert Haas" <robertmh...@gmail.com> wrote: > For most users, the artifacts that have been > introduced by these fine-grained locks are outweighed by the > performance benefits of greater concurrency - but, as you point out, > not necessarily always. That's what I don't understand. I never did point that out. I never suggested it. I never requested a change to the software. I just suggested that we document the artifacts. Ah, well; thanks for the feedback. > With respect to predicate locking, what you're describing is NOT > predicate locking. I never would have considered it to be such except for some people insisting that a true serializable implementation is impossible without predicate locking. Either that assertion is false or this is a form of predicate locking, crude as it might be. > Maybe our > documentation could say something along the lines of "PostgreSQL's > MVCC framework and row-level locking permit a greater degree of > concurrency than some other databases. Even when the transaction > isolation level is set to serializable, serialization anomalies can > occur in the following situations. When it is important to prevent > these anomalies, explicit row-level or table-level locking can be used > at the expense of reduced concurrency." That's responsive to my concern and nicely worded. Thanks. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
