Re: Fwd: dsm_registry: Add detach and destroy features
От | Nathan Bossart |
---|---|
Тема | Re: Fwd: dsm_registry: Add detach and destroy features |
Дата | |
Msg-id | aFAszMKD69AyA4c1@nathan обсуждение исходный текст |
Ответ на | Re: Fwd: dsm_registry: Add detach and destroy features (Sungwoo Chang <swchangdev@gmail.com>) |
Список | pgsql-hackers |
On Mon, Jun 16, 2025 at 09:02:22AM +0900, Sungwoo Chang wrote: > 2025년 6월 14일 (토) 오전 6:50, Nathan Bossart <nathandbossart@gmail.com>님이 작성: >> Could your use-case be handled with a DSA? On the other thread [0], we're >> talking about adding a GetNamedDSA() function, which returns a DSA that you >> can use to allocate and free shared memory as needed. In theory you could >> even detach the DSA if you no longer needed it in a backend, although >> that's probably unnecessary. > > My use-case requires access to the shared memory object through a named key. > Even if we migrate the code to NamedDSA, within the DSA we will need some sort > of a map between the named key and the object to access. So, I think NamedDSA > won't be the solution. Right, you'd need some other shared space for the DSA pointers. In the other thread, I'm using a dshash table (created via GetNamedDSMHash()) to store those for test_dsm_registry [0]. There are probably other ways to do this. > How about when we call destroy, we check if there are other processes > attached to it and if so, we throw an exception? I checked C++ boost > interprocess library [0], and it looks like that's the way boost does. > This way, we can avoid the aforementioned "partitioned" scenario. That might work. [0] https://postgr.es/m/aEyX-9k5vlK2lxjz%40nathan -- nathan
В списке pgsql-hackers по дате отправления: