Re: Fwd: dsm_registry: Add detach and destroy features - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Fwd: dsm_registry: Add detach and destroy features
Date
Msg-id aEydI-VUUdMqbl1q@nathan
Whole thread Raw
In response to Fwd: dsm_registry: Add detach and destroy features  (Sungwoo Chang <swchangdev@gmail.com>)
List pgsql-hackers
On Fri, Jun 13, 2025 at 08:03:00AM +0900, Sungwoo Chang wrote:
>> One of the reasons I avoided adding detach/destroy functionality originally
>> is because this seems difficult to do correctly.  How would an extension
>> ensure that it doesn't end up with one set of backends attached to a new
>> segment and another attached to an old one that is pending deletion?
>
> I used this patch for my extension in a way that you should always detach
> after you are done using the shmem segment. So the situation you described
> would happen in a brief moment, but once the extension finishes its task,
> the shmem segment will be destroyed naturally as all processes detach from
> it.
>
> Would this not be applicable in other extensions?

I suspect detaching/destroying segments would be applicable elsewhere, I'm
just not sure about providing something with the aforementioned behavior.

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.

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

-- 
nathan



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: pg_recvlogical cannot create slots with failover=true
Next
From: Nathan Bossart
Date:
Subject: Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward