Hi,
Greg Stark wrote:
> I think we're still talking past the issue. Predicate locks are not
> row level, nor page level, nor table level. They're locks on
> predicates. Ie, you have to lock against values which aren't actually
> currently in the table at all. You need to be able to detect a
> conflict between a transaction which read rows "WHERE i BETWEEN 1 AND
> 10" and one which tries to insert a row with i=1 even if the first
> transaction didn't see any rows with i=1 (or indeed even if the first
> transaction found no rows at all).
I absolutely agree to that. 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.
> 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.
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?
Regards
Markus Wanner
