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

From Florents Tselai
Subject Re: add function for creating/attaching hash table in DSM registry
Date
Msg-id F2F49C7C-87A7-4410-8048-A4765C758CED@gmail.com
Whole thread Raw
In response to Re: add function for creating/attaching hash table in DSM registry  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: add function for creating/attaching hash table in DSM registry
List pgsql-hackers

> On 11 Jun 2025, at 4:57 PM, Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Wed, Jun 11, 2025 at 07:15:56PM +0530, Rahila Syed wrote:
>>> How can one dsa_allocate in the same area as the returned dshash_table ?
>>> in other words: shouldn't the state->dsa_handle be returned somehow ?
>>
>> +1. FWIW, Having used the DSA apis in my code, I think having the registry
>> return
>> the mapped dsa address or dsa handle will benefit users who use dsa_allocate
>> to allocate smaller chunks within the dsa.
>
> I considered adding another function that would create/attach a DSA in the
> DSM registry, since that's already an intermediate step of dshash creation.
> We could then use that function to generate the DSA in GetNamedDSMHash().
> Would that work for your use-cases, or do you really need to use the same
> DSA as the dshash table for some reason?

In my case the hashtable itself stores dsa_pointers (obviously stuff allocated in the dsa as the hash table itself)
so I think I can’t avoid the necessity of having it.

Unless, you see a good reason not to expose it ?






pgsql-hackers by date:

Previous
From: Shlok Kyal
Date:
Subject: Re: Skipping schema changes in publication
Next
From: Rahila Syed
Date:
Subject: Re: add function for creating/attaching hash table in DSM registry