Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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
> do predicate locking in databases. Most RDBMS use predicate locking
> indexes, ie the locking happens in the index. One might also argue
> it is potentially more efficient design, as TPC-C shows, though such
> cases of application scalability are rare in the extreme and the
> of MVCC is by far the best general approach in terms of ease of use
> performance.
> The example in the docs is not a realistic example, so your new one
> 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
> 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*
> locking in MVCC and write programs that won't work correctly as a
> result.
Understood and agreed.

In response to

pgsql-hackers by date

Next:From: Emmanuel CecchetDate: 2008-12-23 23:44:53
Subject: Re: incoherent view of serializable transactions
Previous:From: Kevin GrittnerDate: 2008-12-23 21:06:01
Subject: Re: incoherent view of serializable transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group