Simon Riggs <simon@xxxxxxxxxxxxxxx> writes: > Your suggested fix to the 2000+ inherited relation problem seemed like > it would apply to an area that most people would never use, yet would > have an effect on anybody using LockAcquire. Just FYI, the proposed fix is already in, and I think it's a net win for anyone. LockCountMyLocks was really an artifact of a lock API that's been superseded by events --- namely the assumption that we want to take locks in the names of particular transactions rather than in the names of particular backends. I put that in around 7.1 or so, primarily to support "session locks" for VACUUM, but designed it the way I did with the idea that subtransactions would someday want it. In the event, subtransactions didn't want it --- it was a lot cheaper to add the backend-private LOCALLOCK tables and make all the subtransaction bookkeeping happen internally to a backend. Now that we have LOCALLOCK the obvious next step is to manage session locks entirely within LOCALLOCK too, and reduce the shared-memory state to essentially one bit per lock per backend: "I hold it" or "I don't hold it". When you know there is only one proclock per backend, there's no need to search for other ones and thus LockCountMyLocks goes away again. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx
