Re: Improve LWLock tranche name visibility across backends
От | Nathan Bossart |
---|---|
Тема | Re: Improve LWLock tranche name visibility across backends |
Дата | |
Msg-id | aHGJBt37dg37f1bE@nathan обсуждение исходный текст |
Ответ на | Re: Improve LWLock tranche name visibility across backends (Sami Imseih <samimseih@gmail.com>) |
Список | pgsql-hackers |
On Fri, Jul 11, 2025 at 04:32:13PM -0500, Sami Imseih wrote: > Now, what I think will be a good API is to provide an alternative to > LWLockRegisterTranche, > which now takes in both a tranche ID and tranche_name. The new API I propose is > LWLockRegisterTrancheWaitEventCustom which takes only a tranche_name > and internally > calls WaitEventCustomNew to add a new wait_event_info to the hash > table. The wait_event_info > is made up of classId = PG_WAIT_LWLOCK and LWLockNewTrancheId(). > > I prefer we implement a new API for this to make it explicit that this > API will both register > a tranche and create a custom wait event. I do not think we should get > rid of LWLockRegisterTranche > because it is used by CreateLWLocks during startup and I don't see a > reason to change that. > See the attached v1. Hm. I was thinking we could have LWLockNewTrancheId() take care of registering the name. The CreateLWLocks() case strikes me as a special path. IMHO LWLockRegisterTranche() should go away. > Is there a concern with a custom wait event to be created implicitly > via the GetNamed* APIs? I'm not sure I see any particular advantage to using custom wait events versus a dedicated LWLock tranche name table. If anything, the limits on the number of tranches and the lengths of the names gives me pause. -- nathan
В списке pgsql-hackers по дате отправления: