From: | Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: introduce dynamic shared memory registry |
Date: | 2023-12-18 08:32:08 |
Message-ID: | 3dcea2e9-c46d-4e4f-8371-9526d1aebc83@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 18/12/2023 13:39, Andrei Lepikhov wrote:
> On 5/12/2023 10:46, Nathan Bossart wrote:
>> I don't presently have any concrete plans to use this for anything, but I
>> thought it might be useful for extensions for caching, etc. and wanted to
>> see whether there was any interest in the feature.
>
> I am delighted that you commenced this thread.
> Designing extensions, every time I feel pain introducing one shared
> value or some global stat, the extension must be required to be loadable
> on startup only. It reduces the flexibility of even very lightweight
> extensions, which look harmful to use in a cloud.
After looking into the code, I have some comments:
1. The code looks good; I didn't find possible mishaps. Some proposed
changes are in the attachment.
2. I think a separate file for this feature looks too expensive.
According to the gist of that code, it is a part of the DSA module.
3. The dsm_registry_init_or_attach routine allocates a DSM segment. Why
not create dsa_area for a requestor and return it?
--
regards,
Andrei Lepikhov
Postgres Professional
Attachment | Content-Type | Size |
---|---|---|
additions.txt | text/plain | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Nikita Malakhov | 2023-12-18 09:05:28 | Re: introduce dynamic shared memory registry |
Previous Message | jian he | 2023-12-18 07:41:19 | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) |