On Mon, Aug 9, 2010 at 3:00 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> That would be one way to tackle the problem, but there are
>> difficulties. If we just created new shared memory segments at need,
>> we might end up with a lot of shared memory segments. I suspect that
>> would get complicated and present many management difficulties - which
>> is why I'm so far of the opinion that we should try to architect the
>> system to avoid the need for this functionality. I don't think it's
>> going to be too easy to provide, short of (as Tom says) moving to the
>> MySQL model of many threads working in a single process.
>
> You could allocate shared memory in chunks and then pass that out to
> requestors, the same way sbrk() does it.
Sure. But I don't think that gets you very far. The management of
the chunks is really hard. I go back to my previous example: you
can't store a pointer that might point to another chunk, because the
chunks won't get mapped into all the address spaces synchronously.
Even if you don't care about doing that (and I bet you do), mapping
and unmapping chunks is a heavyweight operation that requires every
backend to notice that it needs to do something (and, incidentally, if
any of them fail, you pretty much have to PANIC). I just can't
imagine us building a reliable system this way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company