Re: Serializable Isolation without blocking

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Markus Wanner" <markus(at)bluegap(dot)ch>,"Greg Stark" <gsstark(at)mit(dot)edu>
Cc: <nicolas(dot)barbier(at)gmail(dot)com>,<robertmhaas(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Subject: Re: Serializable Isolation without blocking
Date: 2010-01-08 15:10:53
Message-ID: 4B46F69D020000250002E04D@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Markus Wanner <markus(at)bluegap(dot)ch> wrote:
> Greg Stark wrote:

> That's about predicate locks. I've been talking about SIREAD,
> which is a different thing (and which I don't consider to be a
> lock). The SIREAD thingie certainly doesn't help implement
> predicate locks. And predicate locking isn't necessarily
> sufficient to implement truly serializable isolation.

SIREAD locks need to be acquired according to the exact same rules
as "normal" read locks in predicate locking schemes. We're just
using a lock level where the set of locks which conflict with it is
empty. ;-) Predicate locking is clearly necessary and clearly not
sufficient to implement serializable isolation. Was some part of
the Cahill paper unclear on that?

>> That's the hard part. How do you represent such a lock in a way
>> that I can efficiently find it and check for the conflict when it
>> comes time for me to do my insert.
>
> As it's not really a lock, but rather a mark or a tag, SIREAD may
> or may not be implemented atop existing or non-existent locking
> structures, IMO.

Well, the development plan calls for it to start there. Whether a
better way is found during optimization is anybody's guess at this
point.

> I've made my points about implementing SIREAD atop table level or
> row level locking structures. With (non-existent) predicate
> locking, I'm still unsure. It might help to implement SIREAD atop
> such a predicate as well. Predicate tagging?

It seems both respectful and less confusing to adopt the terminology
of those who developed SSI techniques. I could invent new terms for
"vulnerable edges", "dangerous structures", "pivots" and such which
are used in the relevant literature. But I won't. It would just
serve to confuse those who have spent the time to read and
understand the literature.

I'm not quite sure I followed what you were getting at with the
"(non-existent) predicate locking" phrase -- was that just an
acknowledgment that it is exactly what is under development and, as
such, doesn't yet exist; or were you getting at something else?

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2010-01-08 15:12:12 Re: RFC: PostgreSQL Add-On Network
Previous Message Alvaro Herrera 2010-01-08 15:04:35 Re: Add .gitignore files to CVS?