Re: Fwd: dsm_registry: Add detach and destroy features

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Sungwoo Chang <swchangdev(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fwd: dsm_registry: Add detach and destroy features
Date: 2025-06-16 14:40:12
Message-ID: aFAszMKD69AyA4c1@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 16, 2025 at 09:02:22AM +0900, Sungwoo Chang wrote:
> 2025년 6월 14일 (토) 오전 6:50, Nathan Bossart <nathandbossart(at)gmail(dot)com>님이 작성:
>> Could your use-case be handled with a DSA? On the other thread [0], we're
>> talking about adding a GetNamedDSA() function, which returns a DSA that you
>> can use to allocate and free shared memory as needed. In theory you could
>> even detach the DSA if you no longer needed it in a backend, although
>> that's probably unnecessary.
>
> My use-case requires access to the shared memory object through a named key.
> Even if we migrate the code to NamedDSA, within the DSA we will need some sort
> of a map between the named key and the object to access. So, I think NamedDSA
> won't be the solution.

Right, you'd need some other shared space for the DSA pointers. In the
other thread, I'm using a dshash table (created via GetNamedDSMHash()) to
store those for test_dsm_registry [0]. There are probably other ways to do
this.

> How about when we call destroy, we check if there are other processes
> attached to it and if so, we throw an exception? I checked C++ boost
> interprocess library [0], and it looks like that's the way boost does.
> This way, we can avoid the aforementioned "partitioned" scenario.

That might work.

[0] https://postgr.es/m/aEyX-9k5vlK2lxjz%40nathan

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-06-16 14:41:03 Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)
Previous Message Christoph Berg 2025-06-16 14:36:59 Re: CHECKPOINT unlogged data