>>> Simon Riggs <si...@2ndquadrant.com> wrote: > On Tue, 2008-12-23 at 10:10 -0600, Kevin Grittner wrote: > > I think the current docs make too much of a deal about how hard it is to > do predicate locking in databases. Most RDBMS use predicate locking via > indexes, ie the locking happens in the index. One might also argue that > it is potentially more efficient design, as TPC-C shows, though such > cases of application scalability are rare in the extreme and the utility > of MVCC is by far the best general approach in terms of ease of use and > performance. > > The example in the docs is not a realistic example, so your new one is > useful. The one currently in the docs is the simplest case I can see of an anomaly which leaves the database in the wrong state after all the commits go through. I think it should probably be kept for that reason. The out-of-sequence appearance of changes before all commits happen seems much more likely to bite people, though. Agreed? > I would want you to update it though to show how use of row level locks > can be used to enforce correct behaviour when required, so provide a > problem and its solution. It will b useful for people moving from > systems like Sybase that use locking often fall foul of the *lack* of > locking in MVCC and write programs that won't work correctly as a > result. Understood and agreed. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
