Re: dsm_unpin_segment

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dsm_unpin_segment
Date: 2016-08-10 03:03:49
Message-ID: CAEepm=2NiYFj65HKMHngnOiaDXjaP4cbGqn8kQR4xeQ8z-x7Gg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 10, 2016 at 2:43 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2016-08-10 04:34:44 Re: [sqlsmith] Failed assertion in joinrels.c
Previous Message Pavan Deolasee 2016-08-10 02:45:26 Re: Heap WARM Tuples - Design Draft