Re: New feature proposal
От | Marc Munro |
---|---|
Тема | Re: New feature proposal |
Дата | |
Msg-id | 1148063122.26818.34.camel@bloodnok.com обсуждение исходный текст |
Ответ на | Re: New feature proposal (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: New feature proposal
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: