| 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: | Whole Thread | Raw Message | 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 |