Re: dynamically allocating chunks from shared memory

Hi,

On 07/22/2010 12:11 AM, Robert Haas wrote:
> I'm not sure why merging the SLRU pools with shared_buffers would
> benefit from dynamically allocated shared memory.

Well, I'm not sure how you'd merge SLRU pools with shared_buffers. IMO
that inherently leads to the problem of allocating memory dynamically.

With such an allocator, I'd say you just port one module after another
to use that, instead of pre-allocated, fixed portions of shared memory.

> I might be at (or possibly beyond) the limit of my ability to comment
> intelligently on this without looking more at what you want to use
> these imessages for, but I'm still pretty skeptical about the idea of
> storing them directly in shared memory. It's possible, though, that I
> am all wet.

Imessages are meant to be a replacement for unix pipes. (To my
knowledge, those don't spill to disk either, but are blocking as soon as
Linux considers the pipe to be 'full'. Whenever that is. Or am I wrong
here?)

The reasons for replacing them were: they consume lots of file
descriptors, they can only be established between the parent and its
child process (at least for anonymous pipes that's the case) and last
but not least, I got told they still aren't fully portable. Another nice
thing about imessages compared to unix pipes is, that it's a zero-copy
approach.

Hope that makes my opinions and decisions clearer. Thank you for sharing
your concerns and for explaining SLRU to me.

Regards

Markus Wanner