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 по дате отправления: