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: (view raw, whole thread or download thread mbox)
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
> 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
> 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.

In response to


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-2017 The PostgreSQL Global Development Group