Re: New feature proposal
От | Marc Munro |
---|---|
Тема | Re: New feature proposal |
Дата | |
Msg-id | 1148400636.13655.38.camel@bloodnok.com обсуждение исходный текст |
Ответ на | Re: New feature proposal (Marc Munro <marc@bloodnok.com>) |
Список | 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 по дате отправления: