On Thu, Mar 1, 2018 at 3:40 PM, Andres Freund <andres@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
