On Thu, Jan 9, 2014 at 2:22 PM, Robert Haas <robertmh...@gmail.com> wrote:
> It would be nice to have better operating system support for this.
> For example, IIUC, 64-bit Linux has 128TB of address space available
> for user processes.  When you clone(), it can either share the entire
> address space (i.e. it's a thread) or none of it (i.e. it's a
> process).  There's no option to, say, share 64TB and not the other
> 64TB, which would be ideal for us.  We could then map dynamic shared
> memory segments into the shared portion of the address space and do
> backend-private allocations in the unshared part.  Of course, even if
> we had that, it wouldn't be portable, so who knows how much good it
> would do.  But it would be awfully nice to have the option.

You can map a segment at fork time, and unmap it after forking. That
doesn't really use RAM, since it's supposed to be lazily allocated (it
can be forced to be so, I believe, with PROT_NONE and MAP_NORESERVE,
but I don't think that's portable).

That guarantees it's free.

Next, you can map shared memory at explicit addresses (linux's mmap
has support for that, and I seem to recall Windows did too).

All you have to do, is some book-keeping in shared memory (so all
processes can coordinate new mappings).

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to