Hi,
On 07/26/2010 04:31 PM, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of lun jul 26 08:52:46 -0400 2010:
>> Here's another idea. Instead of making imessages use an SLRU, how
>> about having it steal pages from shared_buffers? This would require
>> segmenting messages into small enough chunks that they'd fit, but the
>> nice part is that it would avoid the need to have a completely
>> separate shared memory arena. Ideally, we'd make the infrastructure
>> general enough that things like SLRU could use it also; and get rid of
>> or reduce in size some of the special-purpose chunks we're now
>> allocating.
To me that sounds like solving the same kind of problem for every module
separately and somewhat differently. I tend to like general solutions
(often too much, but that's another story), and to me it still seems a
completely dynamic memory allocator solves that generically (and way
more elegant than 'stealing pages' sounds).
> Right
> now we allocate a single large arena, and the lot of shared_buffers,
> SLRU pools, locking objects, etc are all allocated from there.
Uh.. they all allocate from different, statically sized pool, don't they?
> If we
> want another 2 MB for "dynamic shmem", we'd just allocate 2 MB more in
> that large arena and give those to this new code.
That's how it could work if we used a dynamic allocator. But currently,
if I understand correctly, once the shared_buffers pool is full, it
cannot steal memory from the SLRU pools. Or am I mistaken?
Regards
Markus Wanner
