Re: pg_background (and more parallelism infrastructure patches)

Robert Haas wrote:
> On Fri, Oct 24, 2014 at 4:46 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> > On 10/24/14, 12:21 PM, Robert Haas wrote:
> >> - What should we call dsm_unkeep_mapping, if not that?
> >
> > Only option I can think of beyond unkeep would be
> > dsm_(un)register_keep_mapping. Dunno that it's worth it.
>
> Hmm, we could rename dsm_keep_mapping() to dsm_unregister_mapping(),
> since it's arranging to keep it by unregistering it from the resource
> owner. And then we could call the new function
> dsm_register_mapping(). That has the appeal that "unregister" is a
> word, whereas "unkeep" isn't, but it's a little confusing otherwise,
> because the sense is reversed vs. the current naming. Or we could
> just leave dsm_keep_mapping() alone and call the new function
> dsm_register_mapping(). A little non-orthogonal, but I think it'd be
> OK.

I do think that dsm_keep_mapping is a strange name for what it does. If
it were a single function maybe it'd be okay because you read the
comments and know what it does, but if we have to invent the "unkeep"
stuff then it gets weird enough that a better solution seems worthwhile
to me. So +1 for renaming it to something else. I like the "pin"
analogy we use for buffers; so if you pin a mapping (dsm_pin_mapping)
then it doesn't go away automatically with the resowner, and then you
unpin it (dsm_unpin_mapping) to make the system collect it.

(Not sure what this means for the per-segment equivalent function. It
might be worth keeping both namings consistent.)

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services