> 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
