Hi,
I had use cases for manually detaching and destroying dsm segment while developing my extension (emulating Oracle's DBMS_PIPE package). In this extension user can call user defined procedures that destroy the resources in the shared memory. There were mentions about adding detach features in the original discussion (
introduce dynamic shared memory registry), but it seems like it didn't expand from there.
In the attached patch, dsm_registry not provides two more interfaces: DetachNamedDSMSegment, and DestroyNamedDSMSegment. Detach function simply detaches the corresponding dsm_segment. Destroy function calls dsm_unpin_segment and deletes the dshash entry from the dsm_registry_table. Destroy function may not "destroy" the dsm segment immediately if there are other processes attached to the dsm segment, but it will eventually cause the dsm segment to be destroyed when there are no more processes attached to it. Because Destroy function deletes the entry from the dsm_registry_table, it will block new attachment. It will create a new dsm segment with the same name.
Detach and Destroy functions allows on_detach_callback, which will be passed on to the dsm segment by calling on_dsm_detach. Because on_dsm_detach requires the callback function to have dsm_segment as input, we wrap the library user callback with a function matching to the required signature.
I also made some fix in GetNamedDSMSegment function where it throws an exception if the found entry's size field does not match the user input. It looks like dshash_release_lock needs to be called and MemoryContext needs to be switched back to the old one.
It's my first time submitting a patch so please let me know if I missed on something.
Best regards,
Sungwoo Chang
