Horton

Re: add function for creating/attaching hash table in DSM registry

Rahila Syed <rahilasyed90@gmail.com>

View thread View on postgr.es
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-13T15:01:22Z
Lists: pgsql-hackers 
Hi,


> * Using a DSA from the registry is cumbersome.  You essentially need
>   another batch of shared memory to keep track of the pointers and do
>   locking, so it might not be tremendously useful on its own.  AFAICT the
>   easiest thing to do is to store the DSA pointers in a dshash table, which
>   is what I've done in the test.


I am considering whether it would be better to avoid creating another DSM
segment to
track the DSA handle.
Would it make more sense to track the DSAs in a separate dshash registry
similar
to DSM segments?

+               /* Attach to existing DSA. */
+               dsa = dsa_attach(state->dsah);
+               dsa_pin_mapping(dsa);
+
+               *found = true;
+       }

Should this also consider the case where dsa is already mapped,
to avoid the error on attaching to the DSA twice? IIUC,
that would require calling dsa equivalent of dsm_find_mapping().


Thank you,
Rahila Syed

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.