Re: Documenting serializable vs snapshot isolation levels

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 isolation levels
Date: 2009-01-02 15:38:52
Message-ID: 495DE0AB.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 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

Browse pgsql-hackers by date

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