[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] New feature proposal
From:       Marc Munro <marc () bloodnok ! com>
Date:       2006-05-23 16:10:36
Message-ID: 1148400636.13655.38.camel () bloodnok ! com
[Download RAW message or body]


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

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]