| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Rahila Syed <rahilasyed90(at)gmail(dot)com> |
| Cc: | Florents Tselai <florents(dot)tselai(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: add function for creating/attaching hash table in DSM registry |
| Date: | 2025-06-11 13:57:03 |
| Message-ID: | aEmLL7ieRBHZOY3y@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2025-06-11 13:59:42 | Re: CHECKPOINT unlogged data |
| Previous Message | Rahila Syed | 2025-06-11 13:45:56 | Re: add function for creating/attaching hash table in DSM registry |