On Tuesday 11 November 2003 00:50, Neil Conway wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
> > We can't resize shared memory because we allocate the whole thing in
> > one big hump - which causes the shmmax problem BTW. If we allocate
> > that in chunks of multiple blocks, we only have to give it a total
> > maximum size to get the hash tables and other stuff right from the
> > beginning. But the vast majority of memory, the buffers themself, can
> > be made adjustable at runtime.
>
> Yeah, writing a palloc()-style wrapper over shm has been suggested
> before (by myself among others). You could do the shm allocation in
> fixed-size blocks (say, 1 MB each), and then do our own memory
> management to allocate and release smaller chunks of shm when
> requested. I'm not sure what it really buys us, though: sure, we can
> expand the shared buffer area to some degree, but
Thinking of it, it can be put as follows. Postgresql needs shared memory
between all the backends.
If the parent postmaster mmaps anonymous memory segments and shares them with
children, postgresql wouldn't be dependent upon any kernel resourse aka
shared memory anymore.
Furthermore parent posmaster can allocate different anonymous mappings for
different databases. In addition to postgresql buffer manager overhaul, this
would make things lot better.
note that I am not suggesting mmap to maintain files on disk. So I guess that
should be OK.
I tried searching for mmap on hackers. The threads seem to be very old. One in
1998. with so many proposals of rewriting core stuff, does this have any
chance?
Just a thought.
Shridhar