On Fri, 2006-05-19 at 12:35 -0700, Marc Munro wrote:
> On Fri, 2006-05-19 at 14:44 -0400, Tom Lane wrote:
> > 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 have give this idea some further thought and I agree; Tom's solution
is more bulletproof and is the right way to go. My original proposal is
withdrawn.
I am going to look into the best way to implement this but my gut
feeling is that I would like the support infrastructure for this to be
in Postgres rather than in Veil.
By support infrastructure, I mean APIs to create and access new shared
memory segments, and allocate chunks of memory from those shared
segments.
I think this code is better placed in Postgres rather than in specific
add-ins because: it is functionality that could benefit many add-ins; it
can make use of existing postgres code; and it can be easily tested in
the regression suite using the buildfarm.
I don't want to start working on this without knowing there is a chance
of the patch being acceptable, so feedback is invited.
Thanks.
__
Marc
