On Mon, Aug 9, 2010 at 3:00 PM, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
