the joinedload is explained in the linked changeid  was discussed back in v or thereabouts i see that in fact that has been reverted now about the locking availability ranges are also changed during ip allocation  not only create and here  i am kind of torn  i really like the elegance of your immediate deletion  we have long ago established we do not care about old pools  we are not looking for conflicts etc  so just deleting them makes sense  but  i still feel we can  try our best  to prevent ip allocation from an availability pool which we are currently updating  that involves the lock  complete with joinedload hack  you are right that i do not use that info  i can just use  noload  to include the lock without loading the ranges like pool qry context session query models v  ipallocationpool  options orm noload  available ranges with lockmode  update  anyway  you are the third person advocating for nolock  so i will take the hint  i will simplify it for next v  let s see what others think 