On Wed, Oct 8, 2014 at 6:32 PM, Andres Freund <and...@2ndquadrant.com> wrote: >> /* >> + * Arrange to remove a dynamic shared memory mapping at cleanup time. >> + * >> + * dsm_keep_mapping() can be used to preserve a mapping for the entire >> + * lifetime of a process; this function reverses that decision, making >> + * the segment owned by the current resource owner. This may be useful >> + * just before performing some operation that will invalidate the segment >> + * for future use by this backend. >> + */ >> +void >> +dsm_unkeep_mapping(dsm_segment *seg) >> +{ >> + Assert(seg->resowner == NULL); >> + ResourceOwnerEnlargeDSMs(CurrentResourceOwner); >> + seg->resowner = CurrentResourceOwner; >> + ResourceOwnerRememberDSM(seg->resowner, seg); >> +} > > Hm, I dislike the name unkeep. I guess you want to be symmetric to > dsm_keep_mapping? dsm_manage_mapping(), dsm_ensure_mapping_cleanup() > dm_remember_mapping()?
Yes, I want to be symmetrical with dsm_keep_mapping, which is itself symmetrical with dsm_keep_segment(). Your proposed names don't sound good to me because it's not obvious that "manage" or "remember" is the opposite of "keep". It's pretty easy to remember that "unkeep" is the opposite of "keep" though. If I had to pick one of those, I'd probably pick dsm_ensure_mapping_cleanup(), but I don't like that much. It describes what the function does fairly well, but it's totally unlike the function it pairs with. Another idea is to add another argument to the existing function (possibly renaming it along the way). For example, we could have dsm_keep_mapping(seg, true) mean keep it, and dsm_keep_mapping(seg, false) meaning don't keep it. That would break existing callers, but there probably aren't many of those. We could even - and much more generally - replace it with dsm_set_resowner(seg, res), but that would require #including some some stuff into dsm.h that we might rather not have there. I'll respond to the rest of this later. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers