Re: incoherent view of serializable transactions

>>> Simon Riggs <simon@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