Robert Haas wrote: > OK. I think it will become more clear whether the existing lock > data structures are adequate as you move into detailed design. I've gotten far enough in reviewing it to be pretty convinced that they'll cover all the granularities I'm likely to want unless I get to the point of wanting to try to lock individual columns within individual rows. It probably won't come to that, so I figure I'll cross that bridge if and when I come to it. > As an overall design comment, I sometimes find that it helps to > create a working implementation of something, even if I know that > the performance will suck or that the result will not be > committable for other reasons. There is often value to that just > in terms of getting your head around the parts of the code that > need to be modified. That's exactly where I've been trying to go at this point. > I wonder if you couldn't start with something ridiculously poor, > like maybe an S2PL implementation with only table-level granularity > - just make any operation that reads or writes a table grab an > ACCESS EXCLUSIVE lock until transaction commit. There's an idea I hadn't thought of -- doing S2PL but with ACCESS EXCLUSIVE locks for the read locks to test the predicate locking. It would let me play around with testing that phase before I moved to the next with minimal wasted effort. > Convince yourself that it is CORRECT - forget performance. Then > either change the locks to SIREAD, or try to weaken the locks to > row-level in certain cases. Then do the other one. It'll take you > a while before you have something that can seriously be considered > for commit, but that's not the point. The point is you'll have > working code that you can fool with. We're very much on the same page. My goal was to get predicate locking that didn't miss anything, even though it was ridiculously coarse, then implement the simplest possible SSI on top of it, without worrying about optimizations, then incrementally move toward production quality. I clearly didn't communicate that as well as I'd hoped. :-( Anyway, I'll think about the S2PL with ACCESS EXCLUSIVE locks for reads; if I can't punch any holes in that as a valid environment to test the predicate locking logic, I'll do that first, then switch them to SIREAD locks and work on the SSI logic. > And use git so you can keep merging up to CVS HEAD easily. I know. It's on my list to do soon. Thanks again, -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers