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, [EMAIL PROTECTED] wrote: > Date: Mon, 17 Oct 2005 00:42:17 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: Douglas McNaught <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], > "pgsql-general@postgresql.org" <pgsql-general@postgresql.org> > Subject: Re: dynamic loading of .so > Message-ID: <[EMAIL PROTECTED]> > > Douglas McNaught <[EMAIL PROTECTED]> writes: > > <[EMAIL PROTECTED]> 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 >
signature.asc
Description: This is a digitally signed message part
