Re: add function for creating/attaching hash table in DSM registry
Rahila Syed <rahilasyed90@gmail.com>
From: Rahila Syed <rahilasyed90@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Florents Tselai <florents.tselai@gmail.com>, Sami Imseih <samimseih@gmail.com>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, pgsql-hackers@postgresql.org
Date: 2025-06-20T11:23:52Z
Lists: pgsql-hackers
Hi Nathan, > > I like this idea, but I took it one step further in the attached patch and > made the registry entry struct flexible enough to store any type of entry. > Specifically, I've added a new "type" enum followed by a union of the > different structs used to store the entry data. I was originally trying to > avoid this kind of invasive change, but it's not nearly as complicated as I > feared, and there are benefits such as fewer shared memory things to juggle > and better sanity checking. It should also be easy to extend in the > future. WDYT? > > Thank you for implementing these changes. The improvements look good and enhance the feature's utility. I have already started incorporating GetNamedDSA into my code to display memory context statistics. A potential future enhancement could be allowing GetNamedDSHASH to accept an existing DSA name. This would enable the DSHASH to reuse a DSA area instead of creating a new one each time. I plan to use this registry to store DSA pointers that all belong to the same DSA area, and this enhancement would be particularly beneficial. If you find this idea useful, I would be interested in working on it. Thank you, Rahila Syed
Commits
-
Fix cross-version upgrade test breakage from commit fe07100e82.
- 0c2b7174c362 19 (unreleased) landed
-
Add GetNamedDSA() and GetNamedDSHash().
- fe07100e82b0 19 (unreleased) landed
-
Remove dynamic_shared_memory_type=none
- bcbd940806a2 12.0 cited
-
Introduce dynamic shared memory areas.
- 13df76a537cc 10.0 cited
-
Relax the requirement that all lwlocks be stored in a single array.
- ea9df812d850 9.4.0 cited