Re: Fwd: dsm_registry: Add detach and destroy features
От | Nathan Bossart |
---|---|
Тема | Re: Fwd: dsm_registry: Add detach and destroy features |
Дата | |
Msg-id | aEydI-VUUdMqbl1q@nathan обсуждение исходный текст |
Ответ на | Fwd: dsm_registry: Add detach and destroy features (Sungwoo Chang <swchangdev@gmail.com>) |
Ответы |
Re: Fwd: dsm_registry: Add detach and destroy features
|
Список | pgsql-hackers |
On Fri, Jun 13, 2025 at 08:03:00AM +0900, Sungwoo Chang wrote: >> One of the reasons I avoided adding detach/destroy functionality originally >> is because this seems difficult to do correctly. How would an extension >> ensure that it doesn't end up with one set of backends attached to a new >> segment and another attached to an old one that is pending deletion? > > I used this patch for my extension in a way that you should always detach > after you are done using the shmem segment. So the situation you described > would happen in a brief moment, but once the extension finishes its task, > the shmem segment will be destroyed naturally as all processes detach from > it. > > Would this not be applicable in other extensions? I suspect detaching/destroying segments would be applicable elsewhere, I'm just not sure about providing something with the aforementioned behavior. 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. [0] https://postgr.es/m/aEyX-9k5vlK2lxjz%40nathan -- nathan
В списке pgsql-hackers по дате отправления: