Re: Improve LWLock tranche name visibility across backends
В списке pgsql-hackers по дате отправления:
| От | Nathan Bossart |
|---|---|
| Тема | Re: Improve LWLock tranche name visibility across backends |
| Дата | |
| Msg-id | aIvfFqqIPJjagSgD@nathan обсуждение исходный текст |
| Ответ на | Re: Improve LWLock tranche name visibility across backends (Sami Imseih <samimseih@gmail.com>) |
| Ответы |
Re: Improve LWLock tranche name visibility across backends
|
| Список | pgsql-hackers |
I've attached a rebased version of the patch. On Mon, Jul 21, 2025 at 11:26:44PM -0500, Sami Imseih wrote: > Unlike the local list of tranche names, appending to and searching the > shared memory list requires an LWLock; in exclusive mode to append, and > shared mode to search. The thing that stood out the most to me is how much more expensive looking up the lock name is. At the risk of suggesting even more complexity, I'm wondering if we should add some sort of per-backend cache to avoid the need for locking and dsa_get_address() calls every time you need to look up a lock name. Also, I suspect that there might be some concerns about the API changes. While it should be a very easy fix, that seems likely to break a lot of extensions. I don't know if it's possible to make this stuff backward compatible, and I also don't know if we really want to, as that'll both introduce more complexity and keep folks using the old API. (That being said, I just looked on GitHub and Debian Code Search and was surprised at how few uses of LWLockNewTrancheId() and LWLockRegisterTranche() there are...) -- nathan
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера