On Fri, 2006-05-19 at 14:44 -0400, Tom Lane wrote:
> Marc Munro <marc@bloodnok.com> writes:
> > My proposal makes it possible for properly configured add-ins to have a
> > guaranteed amount of shared memory available.
>
> This could all be solved in a cleaner, more bulletproof way if you
> simply require such add-ins to be preloaded into the postmaster process
> using the existing preload_libraries hook. Then, such an add-in would
> allocate its own shmem segment independent of the main Postgres one.
> This totally eliminates worries about one chunk of code eating the other
> one's memory, which otherwise we'd have to have additional mechanism to
> deal with.
This is an interesting idea that I had not previously considered. I
will give it some thought.
I'm not convinced that we actually do need to prevent add-ins from
eating each other's memory. Just as existing add-ins that use palloc
are expected to use the appropriate memory context and behave
themselves, I would expect the same to be true for add-ins that require
shared memory.
> In a Unix environment, such a thing would Just Work because pointers to
> the new segment would be inherited through fork(). In the Windows port
> you'd need to do more pushups --- perhaps allocate a small amount of
> memory in the main Postgres shmem segment containing the ID of the other
> shmem segment, which a backend would use to reattach.
>
For me, adding windows-specific code to Veil is highly unappealling - I
have no easy way to build or test for windows, and no experience of
doing so, so the more I can leverage the existing functionality, the
better.
I had hoped to simply piggyback on Postgres' existing memory management
with a very small change to effectively add an add-in shared memory
context.
On the other hand, if this is the way we have to go, then perhaps it
could be added to Postgres as part of its api, rather than having Veil,
and perhaps other add-ins, implement it for themselves.
Thoughts?
__
Marc