On Thu, Mar 1, 2018 at 2:17 PM, Andres Freund <and...@anarazel.de> wrote:
>> However, if we take the position that no hash collision probability is
>> low enough and that we must eliminate all chance of false collisions,
>> except perhaps when the table is full, then we have to make this
>> locking mechanism a whole lot more complicated. We can no longer
>> compute the location of the lock we need without first taking some
>> other kind of lock that protects the mapping from {db_oid, rel_oid} ->
>> {memory address of the relevant lock}.
>
> Hm, that's not necessarily true, is it? Wile not trivial, it also
> doesn't seem impossible?
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
