[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] New feature proposal
From:       Marc Munro <marc () bloodnok ! com>
Date:       2006-05-19 18:25:21
Message-ID: 1148063122.26818.34.camel () bloodnok ! com
[Download RAW message or body]


On Fri, 2006-05-19 at 10:05 -0700, Josh Berkus wrote:
> Marc,
> 
> > The add-in would not "know" how much had been allocated to it, but could
> > be told through it's own config file.  I envisage something like:
> >
> > in postgresql.conf
> >
> > # add_in_shmem = 0    # Amount of shared mem to set aside for add-ins
> >                       # in KBytes
> > add_in_shem = 64
> >
> >
> > in veil.conf
> >
> > veil_shmem = 32       # Amount of shared memory we can use from
> >                       # the postgres add-ins shared memory pool
> >
> > I think this is better than add-ins simply stealing from, and contending
> > for, postgres shared memory which is the only real alternative right
> > now.
> 
> Hmmmm ... what would happen if I did:
> 
> add_in_shmem = 64
> veil_shmem = 128
> 
> or even:
> 
> add_in_shmem = 128
> veil_shmem = 64
> plperl_shmem = 64
> pljava_shmem = 64
> 

If that happens, one of the add-ins will be sadly disappointed when it
tries to use its allocation.  The same as would happen now, if Veil
attempted to allocate too large a chunk of shared memory.

My proposal makes it possible for properly configured add-ins to have a
guaranteed amount of shared memory available.  It allows add-ins to be
well-behaved in their use of shared memory, and it prevents them from
being able to exhaust postgres' own shared memory.

It doesn't prevent add-ins from over-allocating from the add-in memory
context, nor do I think it can or should do this.

__
Marc

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]