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

From Nathan Bossart
Subject Re: add function for creating/attaching hash table in DSM registry
Date
Msg-id aEmRcAH1Rmaocz3D@nathan
Whole thread Raw
In response to Re: add function for creating/attaching hash table in DSM registry  (Florents Tselai <florents.tselai@gmail.com>)
List pgsql-hackers
On Wed, Jun 11, 2025 at 05:11:54PM +0300, Florents Tselai wrote:
>> On 11 Jun 2025, at 4:57 PM, Nathan Bossart <nathandbossart@gmail.com> wrote:
>> 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.

Is there any reason these DSA pointers can't be for a separate DSA than
what the dshash table is using?

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

I'm not sure there's any real technical reason, but I guess it feels
cleaner to me to keep the DSM-registry-managed dshash DSAs internal to the
implementation.  Presumably messing with that DSA introduces some risk of
breakage, and it could make it more difficult to change implementation
details for the named dshash code in the future.

-- 
nathan



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: ALTER TABLE ALTER CONSTRAINT misleading error message
Next
From: Dilip Kumar
Date:
Subject: Re: Question on error code selection in conflict detection