Re: A third lock method

I wrote:
> It's just a little bit of a stretch to call SILOCKs locks, because
> they don't actually block anything. They are used at various points
> to see where a transaction is reading data which has been modified
> by another transaction or vice versa. And they do need to be kept
> until all concurrent transactions have completed. Other than those
> quirks, they behave pretty much like read locks, though, so it
> seems to make sense to use the locking system for them. The
> differences are such that I thought a new lock method might be
> appropriate. This thread is to try to solicit opinions on whether
> that makes sense to anyone but me. :-)
> 
> Once I sort out the subject issue, I'm about ready to try to start
> generating a very rough prototype of predicate locking. I don't
> want to start a discussion of those details on this thread, because
> it seems to me that a decision on the subject issue affects
> significant details about how I go about that.
Based on feedback from Robert Haas on another thread, I think this
thread should be considered wrapped.  It seems to me like SIREAD
locks should be handled by a different lock method, but before I go
there I will probably initially develop and test the predicate
locking logic by using ACCESS EXCLUSIVE locks for all reads, just to
confirm correct coverage of the predicates.
Thanks, all.
-Kevin