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
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 |