On Tuesday 11 November 2003 18:55, Jan Wieck wrote:
> Shridhar Daithankar wrote:
> > 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.
>
> And how does a newly mmap'ed segment propagate into a running backend?
It wouldn't. Just like we allocate fixed amount of shared memory at startup
now, we would do same for mmaped segments. Allocate maximum configured on
startup. But it won't be into kernel space as much shared memory segment
would be.
Anyway we wouldn't be mmaping one segment per page. That might be just too
much mmapping. We could just mmap entire configured are and go ahead.
I like the possibility of isolating shared buffers per database in this
approach. I don't know how much useful it would be in practice..
Shridhar