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@postgresql.org
wrote:
> Date: Mon, 17 Oct 2005 00:42:17 -0400
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: Douglas McNaught <doug@mcnaught.org>
> Cc: cristian@clickdiario.com, tjo@acm.org,
> "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
> Subject: Re: dynamic loading of .so
> Message-ID: <12614.1129524137@sss.pgh.pa.us>
>
> Douglas McNaught <doug@mcnaught.org> writes:
> > <cristian@clickdiario.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
>
