On Jun20, 2011, at 15:27 , Radosław Smogura wrote: > 1. mmap some large amount of anonymous virtual memory (this will be maximum > size of shared memory). > ... > 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.
I think this breaks with strict overcommit settings (i.e. vm.overcommit_memory = 2 on linux). To fix that, you'd need a way to tell the kernel (or glibc) to simply reserve a chunk of virtual address space for further user. Not sure if there's a API for that... best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers