Re: add function for creating/attaching hash table in DSM registry
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Florents Tselai <florents.tselai@gmail.com>
Cc: Rahila Syed <rahilasyed90@gmail.com>, Sami Imseih <samimseih@gmail.com>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, pgsql-hackers@postgresql.org
Date: 2025-06-11T14:23:44Z
Lists: pgsql-hackers
On Wed, Jun 11, 2025 at 05:11:54PM +0300, Florents Tselai wrote: >> On 11 Jun 2025, at 4:57 PM, Nathan Bossart <nathandbossart@gmail.com> wrote: >> I considered adding another function that would create/attach a DSA in the >> DSM registry, since that's already an intermediate step of dshash creation. >> We could then use that function to generate the DSA in GetNamedDSMHash(). >> Would that work for your use-cases, or do you really need to use the same >> DSA as the dshash table for some reason? > > In my case the hashtable itself stores dsa_pointers (obviously stuff > allocated in the dsa as the hash table itself) so I think I can’t avoid > the necessity of having it. Is there any reason these DSA pointers can't be for a separate DSA than what the dshash table is using? > Unless, you see a good reason not to expose it ? I'm not sure there's any real technical reason, but I guess it feels cleaner to me to keep the DSM-registry-managed dshash DSAs internal to the implementation. Presumably messing with that DSA introduces some risk of breakage, and it could make it more difficult to change implementation details for the named dshash code in the future. -- nathan
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