Re: New feature proposal - Mailing list pgsql-hackers

From Marc Munro
Subject Re: New feature proposal
Date
Msg-id 1148400636.13655.38.camel@bloodnok.com
Whole thread Raw
In response to Re: New feature proposal  (Marc Munro <marc@bloodnok.com>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Andreas Joseph Krogh
Date:
Subject: Re: file-locking and postmaster.pid
Next
From: Tom Lane
Date:
Subject: Re: file-locking and postmaster.pid