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

Hi,

I made a patch that adds Detach and Destroy functions for dsm registry.

https://commitfest.postgresql.org/patch/5654

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.

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