Thread: pre_load_libraries

I am trying to create an initialisation function that is called using
the  preload_libraries option.

The purpose of this is to set up shared memory for Veil, independant of
postgres' own shared memory.  Simple init functions work fine, but as
soon as I place calls to ShemAlloc, or LWLockAssign, the server startup
simply halts.

Am I being unreasonable in trying to call these functions at this point
of the server startup, or is this just some stupid bug in my code?

I wish to call ShmemAlloc in order to simply create a shared reference
to the Veil shared memory segments that I will set up separately.

Thanks
__
Marc

On Wed, 2006-07-12 at 02:18 -0300, I wrote:
> I am trying to create an initialisation function that is called using
> the  preload_libraries option.
>
> The purpose of this is to set up shared memory for Veil, independant
> of postgres' own shared memory.  Simple init functions work fine, but
> as soon as I place calls to ShemAlloc, or LWLockAssign, the server
> startup simply halts.

To answer my own question, yes I am being unreasonable.  Shared memory
has not been set up at the time that process_preload_libraries is
called.

Since lwlocks are allocated from postgres shared memory, I cannot assign
an lwlock from Veil's initialisation code.  Instead, I can make the
allocation of the lwlock the responsibility of the first session that
uses a Veil function but I need a lock to prevent a race.

My current thinking is to simply subvert one of the existing lwlocks
while I assign my own.  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?

On a related note, I can see no way to release Veil's shared memory
segment when postgres is shut down.   Perhaps I should be thinking about
making the management of such shared memory segments something that
postgres does on behalf of its add-ins, though that seems presumptious.

I'd appreciate any suggestions, pointers, random thoughts, etc.
__
Marc

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?
        regards, tom lane

On Wed, Jul 12, 2006 at 06:47:56PM -0700, Marc Munro wrote:
> On a related note, I can see no way to release Veil's shared memory
> segment when postgres is shut down.   Perhaps I should be thinking about
> making the management of such shared memory segments something that
> postgres does on behalf of its add-ins, though that seems presumptious.

The easiest way is to simply delete the shared memory segment after
you've done the shmat(). The shmat() will hold onto it until postgres
quits and then be cleaned up by the OS.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.