Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin
От | korryd@enterprisedb.com |
---|---|
Тема | Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin |
Дата | |
Msg-id | 1155225319.24313.95.camel@sakai.localdomain обсуждение исходный текст |
Ответ на | Plugins redux (was Re: [PATCHES] PL instrumentation plugin support) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin
|
Список | pgsql-hackers |
<br /><blockquote type="CITE"><pre> <font color="#000000">As for forcing the library load to occur, I propose a new GUC variable</font> <font color="#000000">"backend_load_libraries" that is much like the postmaster's</font> <font color="#000000">preload_libraries, except that the requested library loads happen</font> <font color="#000000">at backend start time instead of in the postmaster. Then we need</font> <font color="#000000">write and document the code only once, and there are other possible</font> <font color="#000000">uses for it besides PL plugins.</font> </pre></blockquote><br /> Any thoughts about where to put the call to process_backend_libraries() (the new function to handlebackend_load_libraries)?<br /><br /> I'm thinking that it should go in PostgresMain(), just after (before?) the callto BeginReportingGUCOptions() - by that time, we know whether we are a superuser and we have processed all GUC options.<br/><br /> Also, should we create an on_proc_exit() handler that would unload all dynamic libraries (specificallyto call the _PG_fini() functions)? <br /><br /> -- Korry<br /><table cellpadding="0" cellspacing="0"width="100%"><tr><td><br /><br /> --<br /> Korry Douglas <a href="mailto:korryd@enterprisedb.com">korryd@enterprisedb.com</a><br/> EnterpriseDB <a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a></td></tr></table>
В списке pgsql-hackers по дате отправления: