>> Cool. Mircea, reckon we can patch this quickly and with low
risk? Or is it high risk at this stage?
> I don't think it's a good moment for this right now. I'm not even
convinced that this is the way go, as it might be cheaper to cache this information than
to calculate it when needed.
Just to clarify, I wasn't reporting a contention point or a
performance issue. I was just puzzled by the design as it's very
different than what I was expecting. I think we should move towards a
design for which we don't really consider the locks to be positioned
on a specific node, they should be free to move around (still
deterministically, I mean on rehash).
Not asking for urgent changes!
+1, you've been quite convincing about this in
Lisbon :-)
However ATM the lock failover is mainly managed by the transaction originator and is not
migrated across during topology changes.