Re: SSI modularity questions

2011/6/28, Robert Haas <robertmhaas(at)gmail(dot)com>:

> You know, it just occurred to me while reading this email that you're
> using the term "predicate lock" in a way that is totally different
> from what I learned in school. What I was taught is that the word
> "predicate" in "predicate lock" is like the word "tuple" in "tuple
> lock" or the word "relation" in "relation lock" - that is, it
> describes *the thing being locked*. In other words, you are
> essentially doing:
>
> LOCK TABLE foo WHERE i = 1;
>
> I think that what you're calling the predicate lock manager should
> really be called the siread lock manager, and all of the places where
> you are "predicate locking" a tuple should really be "siread locking"
> the tuple.

The predicate in the "full table" case is: "any tuple in this table"
(including tuples that don't exist yet, otherwise it wouldn't be a
predicate). The predicate in the index case is: "any tuple that would
be returned by so-and-such index scan" (idem regarding tuples that
don't exist yet, hence "locking the gaps").

The lock semantics (i.e., how conflicts between it and other locks are
defined and treated) are "siread". The thing that it applies to is a
predicate. (I.e., PostgreSQL before SSI already supported some rather
trivial kind of predicate lock: the full table lock.)

Conclusion: I don't see the problem :-).

Nicolas

--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?