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

Re: Documenting serializable vs snapshot isolationlevels

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Simon Riggs" <simon(at)2ndQuadrant(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Documenting serializable vs snapshot isolationlevels
Date: 2009-01-02 15:38:52
Message-ID: 495DE0AB.EE98.0025.0@wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
>>> Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote: 
> On Mon, 2008-12-29 at 18:13 -0600, Kevin Grittner wrote:
> 
>> I hope someone can show me something good I've missed so far.
> 
> You're viewing this in problem-exposed language, unintentionally I'm
> sure.
 
Hmmm....  My meaning was, "I hope someone can point me to a good paper
summarizing the nature and scope of possible anomalies, to save me
time casting about or thinking it through."  If that came of as
"there's nothing good about the current approach," I apologize.  That
was certainly not what I meant to convey.
 
> My viewpoint on this is that database concurrency is a big issue,
> but that the way we do things round here is a major leap forward on
the
> way things happened previously (and still do in older-style DBMS).
 
I absolutely agree.
 
> Our approach to serializable queries is an optimistic one in two
ways:
> It covers most cases, but not all theoretical cases.
 
Not sure about "most".  Referential integrity is a pretty common use
case, and it is not covered without explicit locking.  Many other
common use cases are not, either.  I agree many are, and that the rest
can be worked around easily enough that I wouldn't want to see
blocking introduced to the degree that non-MVCC databases use for
serializable access.
 
Thanks for pointing out a bad choice of words; no need for this to
become muddled over simple misunderstandings.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-01-02 16:01:56
Subject: Re: Significantly larger toast tables on 8.4?
Previous:From: Tom LaneDate: 2009-01-02 15:33:25
Subject: Re: posix_fadvise v22

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