Re: Update on true serializable techniques in MVCC - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Update on true serializable techniques in MVCC
Date
Msg-id 4B28FC9B020000250002D639@gw.wicourts.gov
Whole thread Raw
In response to Re: Update on true serializable techniques in MVCC  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Update on true serializable techniques in MVCC  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
Robert, Please forgive a couple editorial inserts to your statement
-- I hope it clarifies.  If I've distorted your meaning, feel free
to straighten me out.   :-)
Robert Haas <robertmhaas@gmail.com> wrote:
> This thread veered off into a discussion of the traditional
> [predicate locking] technique, rather than the [serializable] one
> in the paper.  I think that's the part Alvaro was responding to.
If you're right about Alvaro's concern -- my rough understanding is
that HOT creates a linked lists of tuples which are mutations of one
another without altering any value which is part of an index.  If
that's anywhere near a correct understanding, I can't see how there
would be a problem with using the described locking techniques with
any tuple on the list.
As an aside, the thesis mentions smart use of multiple locking
granularities only under the "future work" section.  I can't see an
implementation being considered production quality without that, as
without it there would be no way to constrain the space required to
track the locks.  But there is no shortage of literature on how to
do that, so I view such discussions as more appropriate to low-level
implementation discussions should we ever get serious about using
the techniques which are the main thrust of Dr. Cahill's thesis.
If anyone is interested in reviewing recent literature on these
techniques, Dr. Cahill seemed to like (Hellerstein et al., 2007), to
the point where I may well track it down when I'm done pondering the
work which I referenced at the start of this thread.
-Kevin


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Range types
Next
From: Jeff Davis
Date:
Subject: Re: Range types