Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
| От | Robert Haas |
|---|---|
| Тема | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |
| Дата | |
| Msg-id | CA+TgmoYPdA4jUGgwdBEkFWOivq+Vs47REZ-DRf+H7XOvK8DYDQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Moving relation extension locks out of heavyweightlock manager (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: [HACKERS] Moving relation extension locks out of heavyweightlock manager
|
| Список | pgsql-hackers |
On Thu, Mar 1, 2018 at 2:17 PM, Andres Freund <andres@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
В списке pgsql-hackers по дате отправления: