On Sat, Mar 25, 2017 at 12:35 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Alvaro Herrera wrote: >> Per >> https://postgr.es/m/CAEepm=11ma_Z1HoPxPcSCANnh5ykHORa=hca1u1v1+5s_jw...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
