Re: dsm_unpin_segment - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: dsm_unpin_segment
Date
Msg-id CAEepm=2NiYFj65HKMHngnOiaDXjaP4cbGqn8kQR4xeQ8z-x7Gg@mail.gmail.com
Whole thread Raw
In response to Re: dsm_unpin_segment  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On Wed, Aug 10, 2016 at 2:43 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 8/9/16 6:14 PM, Thomas Munro wrote:
>> The can't be static, they need to be in shared memory, because we also
>> want to protect against two *different* backends pinning it.
>
> Right, this would strictly protect from it happening within a single
> backend. Perhaps it's pointless for pin/unpin, but it seems like it would be
> a good thing to have for attach/detach.

Double attach already gets you:
           elog(ERROR, "can't attach the same segment more than once");

Double detach is conceptually like double free, and in fact actually
leads to a double pfree of the backend-local dsm_segment object.  It
doesn't seem like the kind of thing it's easy or reasonable to try to
defend against, since you have no space left in which to store the
state you need to detect double-frees after you've done it once!

-- 
Thomas Munro
http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: Heap WARM Tuples - Design Draft
Next
From: Dilip Kumar
Date:
Subject: Re: [sqlsmith] Failed assertion in joinrels.c