Re: Improve LWLock tranche name visibility across backends
От | Nathan Bossart |
---|---|
Тема | Re: Improve LWLock tranche name visibility across backends |
Дата | |
Msg-id | aKTGF9Fv1ioXa9P5@nathan обсуждение исходный текст |
Ответ на | Re: Improve LWLock tranche name visibility across backends (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Improve LWLock tranche name visibility across backends
|
Список | pgsql-hackers |
On Tue, Aug 19, 2025 at 02:37:19PM -0400, Andres Freund wrote: > On 2025-08-19 13:31:35 -0500, Nathan Bossart wrote: >> On Tue, Aug 19, 2025 at 02:06:50PM -0400, Andres Freund wrote: >> > Possibly stupid question - is it really worth having a dynamic structure here? >> > The number of tranches is strictly bound, it seems like it'd be simpler to >> > have an array of tranch nmes in shared memory. >> >> Tranches can be allocated post-startup with LWLockNewTrancheId() (e.g., >> autoprewarm). > > Sure, but we don't need to support a large number of tranches. Just make it, > idk, 128 entries long. Adding a dynamically allocated dsm to every server > seems like a waste - ever shared mapping makes fork / exit slower... The other issue is that there's presently no limit on the length of a tranche name registered via LWLockRegisterTranche(). Life would become much simpler if we're willing to put a limit on both that and the number of tranches, but thus far we've been trying to avoid it. -- nathan
В списке pgsql-hackers по дате отправления: