Horton

Re: add function for creating/attaching hash table in DSM registry

Florents Tselai <florents.tselai@gmail.com>

View thread
From: Florents Tselai <florents.tselai@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, pgsql-hackers@postgresql.org
Date: 2025-06-11T04:57:07Z
Lists: pgsql-hackers 

> On 10 Jun 2025, at 8:25 PM, Nathan Bossart <nathandbossart@gmail.com> wrote:
> 
> On Tue, Jun 10, 2025 at 07:47:02PM +0300, Florents Tselai wrote:
>> Love this new API.
> 
> Thanks!
> 
>> a minor typo here 
>> + * current backend.  This function gurantees that only one backend
> 
> Fixed.
> 
>> 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.
> 
> Seems fine to me.
> 
> -- 
> nathan
> <v5-0001-simplify-creating-hash-table-in-dsm-registry.patch>

While trying to port some existing DSMR code, I came across this limitation:

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 ?