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, [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 > > -- End of PGP section, PGP failed! -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
