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
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 |