On Sat, Mar 7, 2020 at 10:23 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > I continue to think that we'd be better off getting all of this > out of the heavyweight lock manager. There is no reason why we > should need deadlock detection, or multiple holds of the same > lock, or pretty much anything that LWLocks don't give you.
Well, that was my initial inclination too, but Andres didn't like it. I don't know whether it's better to take his advice or yours. The one facility that we need here which the heavyweight lock facility does provide and the lightweight lock facility does not is the ability to take locks on an effectively unlimited number of distinct objects. That is, we can't have a separate LWLock for every relation, because there ~2^32 relation OIDs per database, and ~2^32 database OIDs, and a patch that tried to allocate a tranche of 2^64 LWLocks would probably get shot down. The patch I wrote for this tried to work around this by having an array of LWLocks and hashing <DBOID, RELOID> pairs onto array slots. This produces some false sharing, though, which Andres didn't like (and I can understand his concern). We could work around that problem with a more complex design, where the LWLocks in the array do not themselves represent the right to extend the relation, but only protect the list of lockers. But at that point it starts to look like you are reinventing the whole LOCK/PROCLOCK division. So from my point of view we've got three possible approaches here, all imperfect: - Hash <DB, REL> pairs onto an array of LWLocks that represent the right to extend the relation. Problem: false sharing for the whole time the lock is held. - Hash <DB, REL> pairs onto an array of LWLocks that protect a list of lockers. Problem: looks like reinventing LOCK/PROCLOCK mechanism, which is a fair amount of complexity to be duplicating. - Adapt the heavyweight lock manager. Problem: Code is old, complex, grotty, and doesn't need more weird special cases. Whatever we choose, I think we ought to try to get Page locks and Relation Extension locks into the same system. They're conceptually the same kind of thing: you're not locking an SQL object, you basically want an LWLock, but you can't use an LWLock because you want to lock an OID not a piece of shared memory, so you can't have enough LWLocks to use them in the regular way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
