From: | "korryd(at)enterprisedb(dot)com" <korryd(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Plugins redux (was Re: [PATCHES] PL instrumentation |
Date: | 2006-08-10 23:03:10 |
Message-ID: | 1155250990.24313.114.camel@sakai.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> > Also, should we create an on_proc_exit() handler that would unload all
> > dynamic libraries (specifically to call the _PG_fini() functions)?
>
> Yeah, I thought about that too, but I'm inclined not to do it;
> it seems like just excess cycles. The process is quitting anyway,
> so the only reason this would be useful is if the library thinks it's
> going to update external or shared state during _PG_fini ... and on
> the whole that sounds like a bad idea. Besides, if a library really
> needs this it can add its own on_proc_exit handler.
It seems a little dangerous for a dynamic library to register an
on_proc_exit() handler. If we ever add support for unloading a dynamic
library, we'll have to add an unregister_on_proc_exit() too. Otherwise,
a dynamic library might register a function pointer with on_proc_exit()
and then leave a dangling pointer when it gets unloaded.
Given that, I assume you don't feel the need to unload old shared
libraries if the user (a superuser) removes an entry from
backend_load_libraries, right?
In fact, it looks _PG_fini() is only called if you *reload* a library,
unless I'm missing something somwhere.
--
Korry Douglas korryd(at)enterprisedb(dot)com
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-08-10 23:20:33 | Re: 8.2 features status |
Previous Message | Merlin Moncure | 2006-08-10 21:01:23 | Re: 8.2 features status |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-11 00:01:55 | Re: Coding style for emacs |
Previous Message | Andrew Dunstan | 2006-08-10 19:12:50 | Re: Coding style for emacs |