On Sat, May 14, 2011 at 1:33 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > Would that risk be substantially worse than it currently is? If a > backend goes into the tank while holding access shared locks, it will > still block access exclusive locks until it recovers. And those > queued access exclusive locks will block new access shared locks from > other backends. How much is risk magnified by the new approach, > going from "any backend holding the lock is tanked" to "any process at > all is tanked"?
I think that's a pretty substantial increase in risk. Consider that there may be 100 backends out there, one of which holds a relevant lock. Needing to wait for all of them to do something instead of just one is quite different. Also, quite apart from the possibility of hanging altogether, the latency would probably be increased quite a bit, and not in a very predictable fashion. I have the impression that most of the problem comes from fighting over CPU cache lines. If that's correct, it may not be important to avoid shared memory access per se; it may be good enough to arrange things so that the shared memory which is accessed is *typically* not being accessed by other backends. > What I'd considered playing with in the past is having > LockMethodLocalHash hang on to an Access Shared lock even after > locallock->nLocks == 0, so that re-granting the lock would be a purely > local operation. Anyone wanting an Access Exclusive lock and not > immediately getting it would have to send out a plea (via SINVA?) for > other processes to release their locallock->nLocks == 0 locks. But > this would suffer from the same problem of tanked processes. Yeah. I have thought about this, too, but as with Noah's suggestion, I think this would make the risk of things hanging up substantially worse than it is now. A backend that, under the present code, wouldn't be holding an AccessShareLock at all, would now be holding one that you'd have to convince it to release. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
