Re: incoherent view of serializable transactions

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Simon Riggs" <simon(at)2ndQuadrant(dot)com>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: incoherent view of serializable transactions
Date: 2008-12-23 21:11:00
Message-ID: 4950FF84.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Emmanuel Cecchet 2008-12-23 23:44:53 Re: incoherent view of serializable transactions
Previous Message Kevin Grittner 2008-12-23 21:06:01 Re: incoherent view of serializable transactions