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 по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: 8.2 features status
Следующее
От: Lukas Smith
Дата:
Сообщение: Re: 8.2 features status