Re: add function for creating/attaching hash table in DSM registry
От | Florents Tselai |
---|---|
Тема | Re: add function for creating/attaching hash table in DSM registry |
Дата | |
Msg-id | 58DB9EB7-4646-4508-84BA-F0F067A7E8BA@gmail.com обсуждение исходный текст |
Ответ на | add function for creating/attaching hash table in DSM registry (Nathan Bossart <nathandbossart@gmail.com>) |
Список | pgsql-hackers |
On 10 Jun 2025, at 7:21 PM, Nathan Bossart <nathandbossart@gmail.com> wrote:On Tue, Jun 10, 2025 at 10:38:29AM -0500, Nathan Bossart wrote:On Mon, Jun 09, 2025 at 07:14:28PM -0500, Sami Imseih wrote:Going back to the original point, DSMRegistryHash and DSMRegistryHash
are built-in, and those names are well-defined and actually refer to
waits related to the mechanism of registering a DSA or a HASH.
I think it will be odd to append "_dsh", but we should at minimum add
a comment in the GetNamedDSMHash explaining this.
This should be addressed in v3.
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?
Unrelated, but it'd probably be a good idea to make sure the segment is
initialized instead of assuming it'll be zeroed out (and further assuming
that DSHASH_HANDLE_INVALID is 0)...
--
nathan
<v4-0001-simplify-creating-hash-table-in-dsm-registry.patch>
Love this new API.
Two minor things
a minor typo here
+ * current backend. This function gurantees that only one backend
Since you made the first step towards decoupling DSMR_NAME_LEN from NAMEDATALEN;
is it worth considering increasing this to 128 maybe?
I’ve used DSMR extensively for namespacing keys etc, and I’ve come close to 50-60 chars at times.
I’m not too fixed on that though.
В списке pgsql-hackers по дате отправления: