From: | Florents Tselai <florents(dot)tselai(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | 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 04:57:07 |
Message-ID: | 272FA2F5-79F3-470A-961F-FEC2DCDEC674@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 10 Jun 2025, at 8:25 PM, Nathan Bossart <nathandbossart(at)gmail(dot)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 ?
From | Date | Subject | |
---|---|---|---|
Next Message | Yugo Nagata | 2025-06-11 04:57:37 | Re: Extend ALTER DEFAULT PRIVILEGES for large objects |
Previous Message | David Rowley | 2025-06-11 04:52:40 | Re: [PATCH] Re: Proposal to Enable/Disable Index using ALTER INDEX |