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

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

iD8DBQBEtaZMUBr6u+c2wkERAmQxAJ0c7nLvzOgCc61FjoEkAr 6vAbgrTwCePFec
yuxhai+fOBsq0cMVJFr2sVA=
=HAnb
-----END PGP SIGNATURE-----

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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.

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

iD8DBQFEtfMzIB7bNG8LQkwRAsjBAJ0RKNW9LAXfldwSGCvir0 kxx53UoACfVtRD
trVMgJ3mTRtGsmHSZXZf80Q=
=lXhx
-----END PGP SIGNATURE-----