Re: Improve LWLock tranche name visibility across backends
| От | Rahila Syed |
|---|---|
| Тема | Re: Improve LWLock tranche name visibility across backends |
| Дата | |
| Msg-id | CAH2L28v0Qf=CrLYVTQP9g6cncHo2bU4P=1NhjSom7rnOjwxKQg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Improve LWLock tranche name visibility across backends (Sami Imseih <samimseih@gmail.com>) |
| Ответы |
Re: Improve LWLock tranche name visibility across backends
|
| Список | pgsql-hackers |
Hi,
Since DSM is not available during postmaster, if we were to create a DSA
segment in place, similar to what's done in StatsShmemInit(), we would also
need to ensure that the initial shared memory is sized appropriately. This is
because it would need to be large enough to accommodate all user-defined
tranches registered during postmaster, without having to rely on new
dsm segments.
From my experimentation, this sizing is not as straightforward as simply
calculating # of tranches * size of a tranche entry.
I still think we should create the dsa during postmaster, as we do with
StatsShmemInit, but it would be better if postmaster keeps its hands off this
dshash and only normal backends can use them.
Thoughts?
Since creating a DSA segment in place during Postmaster startup still requires calculating the size of
the tranche names table including the user-defined tranches, why not use static shared memory to
pre-allocate a fixed sized table and arrays of size NAMEDATALEN to store the names?
If a dshash table is used to store tranche names and IDs, where would the tranche name for this table
be registered?
Thank you,
Rahila Syed
В списке pgsql-hackers по дате отправления: