POSIX question

Поиск
Список
Период
Сортировка
От Radosław Smogura
Тема POSIX question
Дата
Msg-id 86e178841732f74492e1c9a0811814fa@mail.softperience.eu
обсуждение исходный текст
Ответы Re: POSIX question  (Florian Pflug <fgp@phlo.org>)
Re: POSIX question  (Markus Wanner <markus@bluegap.ch>)
Список pgsql-hackers
Hello,
I had some idea with hugepagse, and I read why PostgreSQL doesn't support POSIX (need of nattach). During read about
POSIX/SysVI found this (thread about dynamic chunking shared memory).
 
http://archives.postgresql.org/pgsql-hackers/2010-08/msg00586.php
When playing with mmap I done some approach how to deal with growing files, so...
Maybe this approach could resolve both of above problems (POSIX and dynamic shared memory). Here is idea:
1. mmap some large amount of anonymous virtual memory (this will be maximum size of shared memory).2. init small SysV
chunkfor shmem header (to keep "fallout" requirements)3. SysV remap is Linux specific so unmap few 1st vm pages of step
1.and attach there (2.)3. a. Lock header when adding chunks (1st chunk is header) (we don't want concurrent chunk
allocation)4.allocate some other chunks of shared memory (POSIX is the best way) and put it in shmem header, put there
informationlike chunk id/name, is this POSIX or SysV, some useful flags (hugepage?) needed by reattaching, attach those
in1.4b. unlock 3a
 
Point 1. will no eat memory, as memory allocation is delayed and in 64bit platforms you may reserve quite huge chunk of
this,and in future it may be possible using mmap / munmap to concat chunks / defrag it etc.
 
Mmap guarants that mmaping with mmap_fixed over already mmaped area will unmap old.
A working "preview" changeset applied for sysv_memory.c maybe quite small.
If someone will want to "extend" memory, he may add new chunk (ofcourse to keep header memory continuous number of
chunksis limited).
 
What do you think about this?
Regards,Radek


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe