Re: add function for creating/attaching hash table in DSM registry - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: add function for creating/attaching hash table in DSM registry
Date
Msg-id CAA5RZ0s9Vwsv74ibSErGnP8E4fMPT8-iDgvOr7owaR3p10yi5A@mail.gmail.com
Whole thread Raw
In response to Re: add function for creating/attaching hash table in DSM registry  (Sami Imseih <samimseih@gmail.com>)
List pgsql-hackers
There is also that dynamic tranche named are stored in local backend
look-up table, so if you have some backends that attached some dynamic
hash table
and others that did not, only the ones that registered would be able to
resolve the tranche id to its name.

This is the case which I encountered yesterday, in which I tested 2
backends competing for a LWLock on the dshash table, but a third backend
that did not attach the hashtable reported the wait_event as "extension"
rather than the extension-specified tranche name.

If that third backend attaches the hash table, then it's able to report
the wait_event as the tranche name specified by the extension. So that
could be confusing as 2 wait events could be reported for the same
code path. right?

One way I see around this is for extensions to be able
to register tranches when they are loaded, so every backend knows about
it.Then GetNamedDSMHash could optionally allow you to specify the trancheId
for either DSA or Hash, or both. Otherwise, it would default to the
way this patch
has it now.

--
Sami



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: add function for creating/attaching hash table in DSM registry
Next
From: Masahiko Sawada
Date:
Subject: Re: Improve tab completion for COPY