On 2018-03-01 15:37:17 -0500, Robert Haas wrote:
> 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.
Right, but why does that require a lock?
Greetings,
Andres Freund
