Re: add function for creating/attaching hash table in DSM registry
| От | Florents Tselai |
|---|---|
| Тема | Re: add function for creating/attaching hash table in DSM registry |
| Дата | |
| Msg-id | 272FA2F5-79F3-470A-961F-FEC2DCDEC674@gmail.com обсуждение |
| Ответ на | Re: add function for creating/attaching hash table in DSM registry (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>) |
| Список | 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 ?
В списке pgsql-hackers по дате отправления: