Well, by exposing detach/destory functions at the query level, users will be able to manage dangling shmem in dsm registry if for some reason you cannot access the segment anymore. Otherwise, if a shmem segment becomes orphaned, the only thing you can do to clear the shmem resource is restarting the whole instance. It will have the same functionality as pg_backend_shutdown in a sense that you won't need to call it unless something goes wrong.
Having said that, I admit it's not urgent to implement t the commands yet. Let's wait till the patches are all reviewed and merged, and we can continue the discussion from that point on.
I was thinking, given the forementioned patch is reviewed and merged, it would be nice to add SQL command that allows manually detach or destroy the dsm registry entry.
Not sure I agree with this.
Having some insight into what's going on in shmem it's useful I think;
But exposing detach / destroy at the query level... I don't think so.
Unless there's a compelling story I can't think of .
On that note, the attributes you mentioned (backend_pid, is_pinned, and created_at) will be nice information to have for users to decide which entry to detach or destroy. Especially, is_pinned will be crucial because you cannot unpin the dsm segment twice.
On Thu, Mar 13, 2025 at 06:54:09PM +0200, Florents Tselai wrote: > I扉e been working with the DSM registry API. > I was wondering if it is possible (it doesn愒 look like it) or if it has been discussed: > can we expose a view like pg_shmem_allocations, but fine-grained for every named segment (i.e. created by GetNamedDSMSegment )? > > Currently, there is a "DSM Registry Data" entry in that view, > but iiuc, it愀 only about the top-level hash table the registry uses.
This seems like a generally reasonable idea to me. In theory, it should be easy enough to build something that walks through the DSM registry hash table.
Here's a first attempt towards a view pg_dsm_registry(name, size) that does just that
So, using the test_dsm_registry module as a test bed,
