Re: 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(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

In response to

Responses

Browse pgsql-hackers by date

  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