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