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

> On Mon, Jun 09, 2025 at 03:10:30PM -0500, Sami Imseih wrote:
> > One thing I noticed, and I´m not too fond of, is that the wait_event name shows
> > up with the _dsh suffix:
> >
> > ```
> > postgres=# select query, wait_event, wait_event_type from pg_stat_activity ;
> > query | wait_event
> > | wait_event_type
> > -------------------------------------------------------------------+------------------------
> > +-----------------
> > select 1; | pg_stat_statements_dsh
> > | LWLock
> > ```
> >
> > So the suffix isn´t just an internal name, it´s user-facing now. If we really
> > need to keep this behavior, I think it´s important to document it clearly in
> > the code.
>
> Okay. FWIW we do use suffixes like "DSA" and "Hash" for the built-in
> tranche names (e.g., DSMRegistryDSA and DSMRegistryHash).

I was surprised that I didn’t get the "extension" wait event based on the logic
in GetLWTrancheName, specifically this portion:

/*
It's an extension tranche, so look in LWLockTrancheNames[]. However,
it's possible that the tranche has never been registered in the current
process, in which case give up and return "extension".
*/

In my test setup, I had two backends with pg_stat_statements enabled and
actively counting queries, so they both registered a dynamic hash. The backend
running pg_stat_activity, however, had pg_stat_statements disabled and did not
register a dynamic hash table.

After enabling pg_stat_statements in the pg_stat_activity backend as well,
thus registering a dynamic hash, I then saw an "extension" wait event appear.

It is not expected behavior IMO, and I still need to debug this a bit more,
but it may be something outside the scope of this patch that the patch just
surfaced.

--
Sami