Re: add function for creating/attaching hash table in DSM registry
Florents Tselai <florents.tselai@gmail.com>
From: Florents Tselai <florents.tselai@gmail.com>
To: Nathan Bossart <nathandbossart@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-11T16:08:25Z
Lists: pgsql-hackers
> On 11 Jun 2025, at 5:23 PM, Nathan Bossart <nathandbossart@gmail.com> wrote: > > 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? I guess not. You’re right I can decouple them. > >> 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. You convinced me there :)