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

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/
>>
>>