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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers