Re: like pg_shmem_allocations, but fine-grained for DSM registry ? - Mailing list pgsql-hackers

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.tselai@gmail.com>님이 작성:

On Fri, Mar 14, 2025 at 11:44 PM Florents Tselai <florents.tselai@gmail.com> wrote:

On Fri, Mar 14, 2025 at 4:16 PM Nathan Bossart <nathandbossart@gmail.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/