Hello,
I had some idea with hugepagse, and I read why PostgreSQL doesn't
support POSIX (need of nattach). During read about POSIX/SysV I 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 chunk for 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 information like chunk id/name, is
this POSIX or SysV, some useful flags (hugepage?) needed by reattaching,
attach those in 1.
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 chunks is limited).
What do you think about this?
Regards,
Radek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
