On Sat, Mar 25, 2017 at 12:35 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Alvaro Herrera wrote:
>> Per
>> https://postgr.es/m/CAEepm=11ma_Z1HoPxPcSCANnh5ykHORa=HcA1U1V1+5S_jwPuA@mail.gmail.com
>> it seems that the dsm.c API is a bit inconvenient right now. I proposed
>> in the first patch in that thread to change the API so that a segment is
>> marked as "pinned" if created with no ResourceOwner set as current;
>> which is essentially the same as creating a fake one, then marking the
>> segment as pinned.
>>
>> Thomas agrees with me, so I propose this patch as preparatory work for
>> the autovacuum/BRIN stuff I'm interested in.
>
> Here's the proposed patch.
+1
I'd word this slightly differently:
+ * If there is a CurrentResourceOwner, the new segment is born unpinned and the
+ * resource owner is in charge of destroying it (and will be blamed if it
+ * doesn't). If there's no current resource owner, then the segment starts in
+ * the pinned state, so it'll stay alive until explicitely unpinned.
It's confusing that we've overloaded the term 'pin'. When we 'pin the
mapping', we're disassociating it from the resource owner so that it
will remain attached for longer than the current resource owner scope.
When we 'pin the segment' we are making it survive even if all
backends detach (= an extra secret refcount). What we're talking
about here is not pinning the *segment*, but pinning the *mapping* in
this backend.
How about: "If there is a non-NULL CurrentResourceOwner, the new
segment is associated with it and will be automatically detached when
the resource owner releases. Otherwise it will remain attached until
explicitly detached. Creating or attaching with a NULL
CurrentResourceOwner is equivalent to creating or attaching with a
non-NULL CurrentResourceOwner and then calling dsm_pin_mapping()."
Then dsm_attach() needs to say "See the note above dsm_create() about
the CurrentResourceOwner.", since it's the same deal there.
--
Thomas Munro
http://www.enterprisedb.com
