From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Sungwoo Chang <swchangdev(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: dsm_registry: Add detach and destroy features |
Date: | 2025-06-09 18:59:04 |
Message-ID: | aEcu-FQgrZWdkBA6@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 18, 2025 at 10:05:07AM +0900, Sungwoo Chang wrote:
> +/*
> + * Attempt to destroy a named DSM segment
> + *
> + * This routine attempts to destroy the DSM segment. We unpin the dsm_segment
> + * and delete the entry from dsm_registry_table. This may not destroy the
> + * dsm_segment instantly, but it would die out once all the other processes
> + * attached to this dsm_segment either exit or manually detach from the
> + * dsm_segment.
> + *
> + * Because we deleted the key from dsm_registry_table, calling
> + * GetNamedDSMSegment with the same key would result into creating a new
> + * dsm_segment instead of retrieving the old unpinned dsm_segment.
> + */
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?
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2025-06-09 19:04:43 | Re: strange perf regression with data checksums |
Previous Message | Ilia Evdokimov | 2025-06-09 18:38:27 | Re: using extended statistics to improve join estimates |