Why postgres not providing freeing shared memory?
It does.
You are presumably looking at static shared memory segments which are assigned at server start. Most extensions need to use one of these, of fixed size, for housekeeping and things like storing LWLocks .
But extensions can use DSM or DSA for most of their memory use, giving them flexible storage.
PostgreSQL doesn't have a fully dynamic shared heap with malloc()/free()-like semantics. AFAIK we don't support the use of AllocSet MemoryContext s on DSM-backed shared memory. That might be nice, but it's complicated.
Most extensions use coding patterns like variable length arrays instead.
I strongly advise you to go read the pglogical source code. It demonstrates a lot of the things you will need to understand to write complex extensions that touch multiple databases.
PostgreSQL itself could make this a LOT easier though. pglogical's basic worker and connection management would be considerably simpler if:
- Extensions could add shared catalog relations
- we could access, copy, and struct-embed BackgroundWorkerHandle
- registered bgworkers weren't relaunched after Pg crash-restart (as discussed on prior threads)
- the bgworker registration struct had more than uint32 worth of room for arguments
- extensions could request that Pg maintain extra shmem space for each bgworker for the extension's use (so we didn't have to maintain our own parallel array of shmem entries for each worker and coordinate that with the bgworker's own areas)
I guess I should probably pony up with a patch for some of this....
While I'm at it, there are so many other extension points I wish for, with the high points being:
- Extension-defined syscaches
- Extension-defined locktypes/methods/etc
- More extensible pg_depend
- Hooks in table rewrite
--