From: | Sungwoo Chang <swchangdev(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Fwd: dsm_registry: Add detach and destroy features |
Date: | 2025-06-13 04:53:00 |
Message-ID: | CAAdDe3NPTmaO4gr-QnvMgMLS71=Lm7LM1_vdaXWtUYEJrEjAjw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
---------- Forwarded message ---------
보낸사람: Sungwoo Chang <swchangdev(at)gmail(dot)com>
Date: 2025년 6월 13일 (금) 오전 8:03
Subject: Re: dsm_registry: Add detach and destroy features
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
> 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?
Sorry for the late response.
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?
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2025-06-13 04:53:20 | Re: proposal: schema variables |
Previous Message | Tom Lane | 2025-06-13 04:32:52 | Re: Suggestions for improving \conninfo output in v18 |