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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBEtmlsUBr6u+c2wkERAgTmAJwMETezhc+wh9+h99Euf+ CJM8vATACeNLlD
W8ohMlsQFanhyqfY4q5269c=
=Vru4
-----END PGP SIGNATURE-----