Re: add function for creating/attaching hash table in DSM registry
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Rahila Syed <rahilasyed90@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-30T13:31:44Z
Lists: pgsql-hackers
On Mon, Jun 30, 2025 at 01:29:22PM +0530, Rahila Syed wrote: > /* XXX: Should we verify params matches what table was created with? */ > > Are you planning to address the above before you commit? It seems like a > helpful check since GetNamedDshash takes the params as arguments. That > said, I don't have a strong preference either way. I was not planning on this, primarily because I'm not sure about comparing the function pointers. Note the following comment above the declaration of dshash_parameters: * Compare, hash, and copy functions must be supplied even when attaching, * because we can't safely share function pointers between backends in general. * The user data pointer supplied to the create and attach functions will be * passed to these functions. > I have a question: is there a way to remove the entries from the registry > and free the space? For example, if a user decides to call > dshash_destroy the dshash entry in the registry would no longer be > needed. See the following thread: https://postgr.es/m/flat/CAAdDe3N%3Dj8mbkJJhmU6hTQRUXKEQMoJWsQz7JZyVK%3DrDWnVdiA%40mail.gmail.com -- 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