Hi, Kevin Grittner wrote: > SIREAD locks need to be acquired according to the exact same rules > as "normal" read locks in predicate locking schemes.
Understood. I didn't take that into account at first. Thanks for pointing it out. (Whatever "normal" read locks are...) > We're just > using a lock level where the set of locks which conflict with it is > empty. ;-) Which kind of defeats the purpose of a lock. Anyway, that's a bike-shed discussion, so I might as well agree to calling it a lock. > 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. Okay, so you know my guess ;-) > 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 agree. My intention was to "translate" the literature terms to Postgres hacker slang. At least I had trouble to understand that SIREAD is a lock that doesn't actually block anything. > 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? SIREAD atop predicate locking serves detecting vulnerable edges (I hope I'm using that term correctly here) between newly inserted tuples and reads, right? I was trying to figure if it would make sense to use predicate locking (instead of table or row level locking) as well for detecting vulnerable edges between updated or deleted tuples and reads. At least you'd be free with its granularity (which cannot be said for row or table level locking, for obvious reasons). However, it certainly depends a lot on the implementation of predicate locking, which we don't have, yet, so that's all speculation... 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
