On Wed, Mar 19, 2025, 05:46 Sungwoo Chang <swchang...@gmail.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.tse...@gmail.com>님이 작성: > >> >> >> >> >> 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/ >> >>
