On Wed, Jan 24, 2018 at 8:37 PM, Gaddam Sai Ram
<gaddamsairam.n@zohocorp.com> wrote:
> Found that there is a callback for dsa detach but that function requires
> segment pointer as an argument, Should be as below:
>
> on_dsm_detach(PROC_DSA_AREA->segment_maps[0].segment, detach_func);
> ...
> But i couldn't access that segment, as DSA_AREA struct is defined in dsa.c,
> so I am unable to include.
>
> Any other ways to get dsa detach event, or to access DSA Segment pointer?
There are two ways to create DSA areas: dsa_create() and
dsa_create_in_place(). In all existing in-core uses of DSA areas,
they are created "in place". That means that you have to supply the
initial DSM segment and then they live inside that, and they will
quietly create more DSM segments as needed if they run out of space.
If you do it that way you get to install detach hooks for that root
DSM segment because you have your hands on it. Maybe you should do
that too? Basically just replace your current DSA creation, handle
sharing and attaching code with the DSM equivalents (make it, say, 1MB
in size), and then use dsa_{create,attach}_in_place() in the space
inside it. The easiest way would be to give *all* the space in this
root DSM segment using dsm_segment_address() to get the "place" to put
the DSA area, or you could use a shm_toc to put that + other fixed
size stuff inside it (the way execParallel.c does).
It probably seems a bit weird and circular that DSA areas manage a set
of DSM segments, but can themselves live in a user-supplied DSM
segment. DSM segments have two roles: they are shared memory, and in
this capacity a DSA area owns and uses them as raw storage, but they
are also a kind of general shared resource ownership/management
mechanism that comes with some free shared space, and in this capacity
they can be used to own a DSA area (or shared files, or interprocess
queues, or ..).
Hope that helps.
--
Thomas Munro
http://www.enterprisedb.com
