On Aug 22, 2011, at 6:22 PM, Robert Haas wrote: > With respect to a general-purpose shared memory allocator, I think > that there are cases where that would be useful to have, but I don't > think there are as many of them as many people seem to think. I > wouldn't choose to implement this using a general-purpose allocator > even if we had it, both because it's undesirable to allow this or any > subsystem to consume an arbitrary amount of memory (nor can it fail... > especially in the abort path) and because a ring buffer is almost > certainly faster than a general-purpose allocator. We have enough > trouble with palloc overhead already. That having been said, I do > think there are cases where it would be nice to have... and it > wouldn't surprise me if I end up working on something along those > lines in the next year or so. It turns out that memory management is > a major issue in lock-free programming; you can't assume that it's > safe to recycle an object once the last pointer to it has been removed > from shared memory - because someone may have fetched the pointer just > before you removed it and still be using it to examine the object. An > allocator with some built-in capabilities for handling such problems > seems like it might be very useful....
Actually, I wasn't thinking about the system dynamically sizing shared memory on it's own... I was only thinking of providing the ability for a user to change something like shared_buffers and allow that change to take effect with a SIGHUP instead of requiring a full restart. I agree that we'd have to be very careful with allowing the code to start changing shared memory size on it's own... -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
