On Fri, Mar 14, 2025 at 11:44 PM Florents Tselai <florents.tse...@gmail.com> wrote:
> > On Fri, Mar 14, 2025 at 4:16 PM Nathan Bossart <nathandboss...@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/
v3-0001-pg_dsm_registry-view.patch
Description: Binary data
