From: | Sungwoo Chang <swchangdev(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Fwd: dsm_registry: Add detach and destroy features |
Date: | 2025-06-16 00:02:22 |
Message-ID: | CAAdDe3OMVtGeRszYCTb_Qcrm8bbPX0DO66L-iGTQU4Wy3fPqJw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2025년 6월 14일 (토) 오전 6:50, Nathan Bossart <nathandbossart(at)gmail(dot)com>님이 작성:
> 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
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.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitrios Apostolou | 2025-06-16 01:06:56 | [WIP PATCH v3] Implement "pg_restore --data-only --clean" as a way to skip WAL |
Previous Message | Arseniy Mukhin | 2025-06-15 22:25:40 | Re: Amcheck verification of GiST and GIN |