Re: dsm_unpin_segment

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: dsm_unpin_segment
Дата
Msg-id CAEepm=2NiYFj65HKMHngnOiaDXjaP4cbGqn8kQR4xeQ8z-x7Gg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: dsm_unpin_segment  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список 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 по дате отправления:

Предыдущее
От: Pavan Deolasee
Дата:
Сообщение: Re: Heap WARM Tuples - Design Draft
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: [sqlsmith] Failed assertion in joinrels.c