Re: Something fishy happening on frogmouth

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Something fishy happening on frogmouth
Дата
Msg-id 52775A83.7090206@vmware.com
обсуждение исходный текст
Ответ на Re: Something fishy happening on frogmouth  (Noah Misch <noah@leadboat.com>)
Ответы Re: Something fishy happening on frogmouth  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On 01.11.2013 18:22, Noah Misch wrote:
> On Fri, Nov 01, 2013 at 12:27:31AM -0400, Robert Haas wrote:
>> On Thu, Oct 31, 2013 at 7:48 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
>>> On 31.10.2013 16:43, Robert Haas wrote:
>>>> There should be no cases where the main shared memory
>>>> segment gets cleaned up and the dynamic shared memory segments do not.
>>>
>>> 1. initdb -D data1
>>> 2. initdb -D data2
>>> 3. postgres -D data1
>>> 4. killall -9 postgres
>>> 5. postgres -D data2
>>>
>>> The system V shmem segment orphaned at step 4 will be cleaned up at step 5.
>>> The DSM segment will not.
>
> Note that dynamic_shared_memory_type='mmap' will give the desired behavior.

Hmm, here's another idea:

Postmaster creates the POSIX shared memory object at startup, by calling 
shm_open(), and immediately calls shm_unlink on it. That way, once all 
the processes have exited, the object will be removed automatically. 
Child processes inherit the file descriptor at fork(), and don't need to 
call shm_open, just mmap().

I'm not sure how dynamic these segments need to be, but if 1-2 such file 
descriptors is not enough, you could mmap() different offsets from the 
same shmem object for different segments.

- Heikki



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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: [v9.4] row level security
Следующее
От: Craig Ringer
Дата:
Сообщение: What stopped SECURITY BARRIER views from being auto-updatable?