Re: Posix Shared Mem patch

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Posix Shared Mem patch
Дата
Msg-id CA+TgmoaJjjpRv7Px+aipSs_pZR7HPmwCfB8G_kf0ZKBUruC79Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Posix Shared Mem patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Posix Shared Mem patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Posix Shared Mem patch  ("A.M." <agentm@themactionfaction.com>)
Список pgsql-hackers
On Wed, Jun 27, 2012 at 12:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> So, here's a patch.  Instead of using POSIX shmem, I just took the
>> expedient of using mmap() to map a block of MAP_SHARED|MAP_ANONYMOUS
>> memory.  The sysv shm is still allocated, but it's just a copy of
>> PGShmemHeader; the "real" shared memory is the anonymous block.  This
>> won't work if EXEC_BACKEND is defined so it just falls back on
>> straight sysv shm in that case.
>
> Um.  I hadn't thought about the EXEC_BACKEND interaction, but that seems
> like a bit of a showstopper.  I would not like to give up the ability
> to debug EXEC_BACKEND mode on Unixen.
>
> Would Posix shmem help with that at all?  Why did you choose not to
> use the Posix API, anyway?

It seemed more complicated.  If we use the POSIX API, we've got to
have code to find a non-colliding name for the shm, and we've got to
arrange to clean it up at process exit.  Anonymous shm doesn't require
a name and goes away automatically when it's no longer in use.

With respect to EXEC_BACKEND, I wasn't proposing to kill it, just to
make it continue to use a full-sized sysv shm.

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


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

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: [v9.3] Row-Level Security
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: proof concept - access to session variables on client side