Re: [BUGS] Patch to allow C extension modules to initialize/finish
От | Gregory Stark |
---|---|
Тема | Re: [BUGS] Patch to allow C extension modules to initialize/finish |
Дата | |
Msg-id | 87mzakqdsb.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: [BUGS] Patch to allow C extension modules to initialize/finish (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] Patch to allow C extension modules to initialize/finish
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > No, my thought is that you'd rename PL/R's init function to PG_init, and > then it'd get called automagically without needing to assume that the DBA > remembers to specify it in preload_libraries. If there's a reason *not* > to do that then it'd be a strike against this whole proposal, methinks. If I understand the question correctly it hinges on whether you want to do all the initialization pre-fork or post-fork? I'm pretty sure you have to allow for both possibilities. I know when I was using mod_perl heavily we wanted to load as many perl modules and code pre-fork as possible. The more we loaded pre-fork the more memory was shared across processes and the more processes we could run on a box without suffering from memory pressure. On the other side the classic case of something that cannot be set up pre-fork is actually database connections :) So, for example if for someone wanted to have a persistent Oracle connection they could not open it pre-fork at library load time but they might want to open it immediately after the fork rather than when it's first used. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: