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

Uh, why does Veil have to allocate space from the backend shared memory
pool rather than allocating its own shared memory segment?

---------------------------------------------------------------------------

Marc Munro wrote:
-- Start of PGP signed section.
> 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
> >
-- End of PGP section, PGP failed!

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073