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

  1. Fix cross-version upgrade test breakage from commit fe07100e82.

  2. Add GetNamedDSA() and GetNamedDSHash().

  3. Remove dynamic_shared_memory_type=none

  4. Introduce dynamic shared memory areas.

  5. Relax the requirement that all lwlocks be stored in a single array.