From: | Marc Munro <marc(at)bloodnok(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Subject: | Re: dynamic loading of .so (originally from pgsql-general) |
Date: | 2005-10-17 15:58:33 |
Message-ID: | 1129564713.13930.31.camel@bloodnok.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-10-17 16:05:31 | Re: Possible issue with win32 installer(8.1beta 3)... |
Previous Message | Martijn van Oosterhout | 2005-10-17 15:54:48 | Re: PostgreSQL roadmap for 8.2 and beyond. |