Horton

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

Sami Imseih <samimseih@gmail.com>

View thread View on postgr.es
From: Sami Imseih <samimseih@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Florents Tselai <florents.tselai@gmail.com>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, pgsql-hackers@postgresql.org
Date: 2025-06-10T18:32:55Z
Lists: pgsql-hackers 
> I'm not quite following your uneasiness with the tranche names.  For the
> dshash table, we'll need a tranche for the DSA and one for the hash table,
> so presumably any wait events for those locks should be named accordingly,
> right?

I may be alone in this opinion, but I prefer the suffixless tranche name for
the primary LWLock (the hash table), as this is the lock users will encounter
most frequently in wait events, like when adding or looking up entries.

Adding a suffix (e.g., "Hash") may be confusing to the extension. In the tests
that I did with pg_stat_statements, I’d rather see "pg_stat_statements" remain
as-is, rather than "pg_stat_statements Hash".

On the other hand, adding a suffix to the DSA tranche name (e.g.,
"pg_stat_statements DSA") is necessary to differentiate it from the Hash
tranche name, and that is OK because it's not likely to be a user-visible wait
event.

--
Sami

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.