On Thu, 2006-07-13 at 01:13 -0300, Tom Lane wrote: > Marc Munro <[EMAIL PROTECTED]> 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
signature.asc
Description: This is a digitally signed message part
