On Thu, Mar 1, 2018 at 3:40 PM, Andres Freund <and...@anarazel.de> wrote: >> You can't both store every lock at a fixed address and at the same >> time put locks at a different address if the one they would have used >> is already occupied. > > Right, but why does that require a lock?
Maybe I'm being dense here but ... how could it not? If the lock for relation X is always at pointer P, then I can compute the address for the lock and assume it will be there, because that's where it *always is*. If the lock for relation X can be at any of various addresses depending on other system activity, then I cannot assume that an address that I compute for it remains valid except for so long as I hold a lock strong enough to keep it from being moved. Concretely, I imagine that if you put the lock at different addresses at different times, you would implement that by reclaiming unused entries to make room for new entries that you need to allocate. So if I hold the lock at 0x1000, I can probably it will assume it will stay there for as long as I hold it. But the instant I release it, even for a moment, somebody might garbage-collect the entry and reallocate it for something else. Now the next time I need it it will be elsewhere. I'll have to search for it, I presume, while holding some analogue of the buffer-mapping lock. In the patch as proposed, that's not needed. Once you know that the lock for relation 123 is at 0x1000, you can just keep locking it at that same address without checking anything, which is quite appealing given that the same backend extending the same relation many times in a row is a pretty common pattern. If you have a clever idea how to make this work with as few atomic operations as the current patch uses while at the same time reducing the possibility of contention, I'm all ears. But I don't see how to do that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
