Re: like pg_shmem_allocations, but fine-grained for DSM registry ?

Well, by exposing detach/destory functions at the query level, users will
be able to manage dangling shmem in dsm registry if for some reason you
cannot access the segment anymore. Otherwise, if a shmem segment becomes
orphaned, the only thing you can do to clear the shmem resource is
restarting the whole instance. It will have the same functionality as
pg_backend_shutdown in a sense that you won't need to call it unless
something goes wrong.

Having said that, I admit it's not urgent to implement t the commands yet.
Let's wait till the patches are all reviewed and merged, and we can
continue the discussion from that point on.

Best regards,

Sungwoo Chang

2025년 3월 19일 (수) 14:43, Florents Tselai <florents(dot)tselai(at)gmail(dot)com>님이 작성:

>
>
> On Wed, Mar 19, 2025, 05:46 Sungwoo Chang <swchangdev(at)gmail(dot)com> wrote:
>
>> Hi,
>>
>> I made a patch that adds Detach and Destroy functions for dsm registry.
>>
>> https://commitfest.postgresql.org/patch/5654
>>
> Yes, I've been following that thread.
> I find it useful too
>
>> I was thinking, given the forementioned patch is reviewed and merged, it
>> would be nice to add SQL command that allows manually detach or destroy the
>> dsm registry entry.
>>
>
> Not sure I agree with this.
> Having some insight into what's going on in shmem it's useful I think;
> But exposing detach / destroy at the query level... I don't think so.
> Unless there's a compelling story I can't think of .
>
>> On that note, the attributes you mentioned (backend_pid, is_pinned, and
>> created_at) will be nice information to have for users to decide which
>> entry to detach or destroy. Especially, is_pinned will be crucial because
>> you cannot unpin the dsm segment twice.
>>
>> Best regards,
>> Sungwoo Chang
>>
>>
>> 2025년 3월 15일 (토) 17:42, Florents Tselai <florents(dot)tselai(at)gmail(dot)com>님이 작성:
>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 14, 2025 at 11:44 PM Florents Tselai <
>>> florents(dot)tselai(at)gmail(dot)com> wrote:
>>>
>>>>
>>>> On Fri, Mar 14, 2025 at 4:16 PM Nathan Bossart <
>>>> nathandbossart(at)gmail(dot)com> wrote:
>>>>
>>>>> On Thu, Mar 13, 2025 at 06:54:09PM +0200, Florents Tselai wrote:
>>>>> > I扉e been working with the DSM registry API.
>>>>> > I was wondering if it is possible (it doesn愒 look like it) or if it
>>>>> has been discussed:
>>>>> > can we expose a view like pg_shmem_allocations, but fine-grained for
>>>>> every named segment (i.e. created by GetNamedDSMSegment )?
>>>>> >
>>>>> > Currently, there is a "DSM Registry Data" entry in that view,
>>>>> > but iiuc, it愀 only about the top-level hash table the registry uses.
>>>>>
>>>>> This seems like a generally reasonable idea to me. In theory, it
>>>>> should be
>>>>> easy enough to build something that walks through the DSM registry hash
>>>>> table.
>>>>>
>>>>
>>>> Here's a first attempt towards a view pg_dsm_registry(name, size) that
>>>> does just that
>>>> So, using the test_dsm_registry module as a test bed,
>>>>
>>>> it would look like this.
>>>>
>>>> CREATE EXTENSION test_dsm_registry;
>>>> SELECT set_val_in_shmem(1236);
>>>> set_val_in_shmem
>>>> ------------------
>>>>
>>>> (1 row)
>>>>
>>>> -- 20 bytes = int (4 bytes) + LWLock (16bytes)
>>>> SELECT * FROM pg_dsm_registry;
>>>> name | size
>>>> -------------------+------
>>>> test_dsm_registry | 20
>>>> (1 row)
>>>>
>>>> I'll create a cf entry to keep track of this
>>>>
>>>>
>>> Here's an updated v3 that fixes some white spaces v2 had—no other
>>> changes.
>>>
>>> I'm wondering though if it also makes sense to expose:
>>> - backend_pid (who created the segment)
>>> - is_pinned bool
>>> - created_at
>>>
>>> https://commitfest.postgresql.org/patch/5652/
>>>
>>>