Re: Retain dynamic shared memory segments for postmaster lifetime

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Retain dynamic shared memory segments for postmaster lifetime
Дата
Msg-id CA+TgmoZR9FE0GdaqCZcqJaim5-0ogc6nBMLstRgeZudjTuMciw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Retain dynamic shared memory segments for postmaster lifetime  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
On Tue, Jan 28, 2014 at 6:12 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> I had a short look on this patch.
>
>  - DSM implimentation seems divided into generic part (dsm.c) and
>    platform dependent part(dsm_impl.c). This dsm_keep_segment
>    puts WIN32 specific part directly into dms.c. I suppose it'd
>    be better defining DSM_OP_KEEP_SEGMENT and calling dms_impl_op
>    from dms_keep_segment, or something.

That might not be a very good fit, but maybe there should be a
separate function exposed by dsm_impl.c to do the
implementation-dependent part of the work; it would be a no-op except
on Windows.

>  - Repeated calling of dsm_keep_segment even from different
>    backends creates new (orphan) handles as many as it is called.
>    Simplly invoking this function in some of extensions intending
>    to stick segments might results in so many orphan
>    handles. Something to curb that situation would be needed.

I don't really think this is a problem.  Let's just document that
dsm_keep_segment() should not be called more than once per segment.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Suspicion of a compiler bug in clang: using ternary operator in ereport()
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: updated emacs configuration