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
providingthe ability for a user to change something like shared_buffers and allow that change to take effect with a
SIGHUPinstead 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 jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
