Re: dynamic loading of .so (originally from pgsql-general)

Tom,
My project, Veil, steals some of this shared memory for itself. I wan't
aware of the "slop factor" and was pleased that it just worked. I guess
I should have been asking questions of this group. Sorry.

I would like Veil to be a good citizen and place a legitimate request
for its shared memory (probably about 16K normally).

Veil is loaded as a shared library, which I would assume means that it
is not present during database startup, making contributing to the
sizing calculation and racing the lockmgr a little tricky.

I see a number of possibilities:

- Have a GUC to allocate shmem space for add-ons
- Have add-ons register themselves and provide hooks for sizing and
initial space allocation
- Let add-ons race with the lockmgr for the slop (ie leave as it is)

Thoughts?

I would be happy to work on this and provide whatever patches are
necessary.

Thanks.
__
Marc Munro

On Mon, 2005-10-17 at 10:34 -0300, pgsql-general-owner(at)postgresql(dot)org
wrote:
> Date: Mon, 17 Oct 2005 00:42:17 -0400
> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> To: Douglas McNaught <doug(at)mcnaught(dot)org>
> Cc: cristian(at)clickdiario(dot)com, tjo(at)acm(dot)org,
> "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
> Subject: Re: dynamic loading of .so
> Message-ID: <12614(dot)1129524137(at)sss(dot)pgh(dot)pa(dot)us>
>
> Douglas McNaught <doug(at)mcnaught(dot)org> writes:
> > <cristian(at)clickdiario(dot)com> writes:
> >> are there any way to make them global for all the instances?
>
> > Put them in shared memory. This probably isn't trival, as all the
> > shared memory is allocated up front and used for existing purposes
> (at
> > least, as I understand it).
>
> There's a "slop factor" of 100KB or so in the shared memory size
> calculation, which means that an add-on library that requests space
> soon
> enough could probably get away with allocating up to a few KB without
> causing any problems. (The slop is not totally useless, since for
> instance the lock manager might eat it up if more locks get requested
> than expected.)
>
> In the long run it might be interesting to add hooks that allow
> preloaded libraries to contribute to the shmem sizing calculation and
> then to snarf up the space they've requested before it can get eaten
> by
> the lockmgr.
>
> regards, tom lane
>