New shared memory hooks proposal (was Re: pre_load_libraries)

Started by Marc Munroover 19 years ago1 messages
#1Marc Munro
marc@bloodnok.com

On Thu, 2006-07-13 at 01:13 -0300, Tom Lane wrote:

Marc Munro <marc@bloodnok.com> writes:

... A better solution from my point of view would be
to simply move the call to process_preload_libraries to a point

after

shared memory has been set up. Is there some reason this could not

be

done?

That would make it impossible for a preloaded library to request any
shared memory of its own --- something that admittedly we don't have a
hook to support, but do we want to foreclose it permanently?

That does sound like the right way to go. Here is my new proposal:

Add-ins register their requirement for shared memory using a new
function: RegisterShmemRequirement(char *context_name, int size). This
would be called by the init function called from
process_preload_libraries.

When shared memory is initialised, extra space is allocated for each
registered add-in. Each add-in's registered allocation is a separate
memory context identified by the context_name parameter provided during
registration.

Add-ins allocate shared memory from their own context using a new
function ShemAddinAlloc(), which adds the context_name parameter to the
normal ShemAlloc parameter list.

This would save add-ins from having to manage their own shared memory
segements while providing a degree of separation and isolation so that
one add-in could not exhaust the shared memory of another or of the
backend.

If this is acceptable, I think it is within my skill level to implement.
Comments?

__
Marc