>>> "Robert Haas" <robertmhaas(at)gmail(dot)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