Hi,
On 08/09/2010 05:41 PM, Tom Lane wrote:
> ... and on some platforms, it'll be flat out impossible. We looked at
> this years ago and concluded that changing the size of the shmem segment
> after postmaster start was impractical from a portability standpoint.
> I have not seen anything to change that conclusion.
I haven't tried, but I tend to believe that's true.
However, I'd like to get back to the original intent of the posted
patch. Which is about dynamically allocating memory *within a fixed size
pool*.
That's something SRLU or shared_buffers do to some extent, but with lots
of limitations. And without the ability to move free memory between
sub-systems (i.e. between different SLRU buffers).
> You meant "I don't think", right? I agree. The only way threads would
> simplify this is if we went over to a mysql-style model where there was
> only one process, period, and all backends were threads inside that.
> No shared memory as such, at all.
That's how the threaded model normally is used, yes. And with that
model, allocation of shared memory is very easy. It has none of the
pre-allocation requirements we are currently facing.
Regards
Markus Wanner