"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> 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.
True, but there might be other uses for such a
> 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
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> Any thoughts about where to put the call to process_backend_libraries()
> (the new function to handle backend_load_libraries)?
> I'm thinking that it should go in PostgresMain(), just after (before?)
> the call to BeginReportingGUCOptions() - by tha
As for forcing the library load to occur, I propose a new GUC variable
"backend_load_libraries" that is much like the postmaster's
preload_libraries, except that the requested library loads happen
at backend start time instead of in the postmaster. Then we need
write and document the code o
On Wed, 2006-08-09 at 18:04 -0400, Tom Lane wrote:
> >> BTW, is anyone up for renaming the existing "preload_libraries"
> variable
> >> to "postmaster_load_libraries"? This would be more symmetrical
> with
> >> "backend_load_libraries", and so perhaps clearer about which does
> what
>
> > Makes s
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
>>> (there is no UNLOAD statement, is there?).
>>
>> What we actually have at the moment is that you can LOAD a library
>> again, which causes an unload of the prior version and then loading the
>> new.
> Right, but you still end up with a plugin lo
I'm not sure you'll be able to convince everyone that the penalty is so
negligible --- any high-rate access to shared memory is potentially very
expensive, see nearby threads for examples. Even if this is affordable
for the debugger, what of more-invasive plugins such as the performance
moni
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
>> The other, probably more controversial bit of functionality is that there
>> needs to be a way to cause a backend to load a PL plugin shared library
>> without any cooperation from the connected client application.
> Ok, but you should know that t
ISTM there are two separate bits of functionality that the core backend
needs to provide in support of PL plugins. The first is that we need a
"rendezvous" facility whereby two separately-loaded shared libraries can
connect and exchange data (a struct of function pointers for the immediate
Jeff Davis <[EMAIL PROTECTED]> writes:
> I know this is a trivial question, but is there some kind of lock that
> would prevent the PG_fini for the plpgsql debugger from executing after
> "if(*plugin_ptr)" and before "((*plugin_ptr)->function_field)(...)"?
Backends are not multi-threaded.
On Wed, 2006-08-09 at 12:44 -0400, Tom Lane wrote:
> A plugin such as a plpgsql debugger would do this in its _PG_init()
> function:
>
> static PLpgSQL_plugin my_plugin = { ... function addresses ... };
>
> PLpgSQL_plugin **var_ptr;
>
> var_ptr = (PLpgSQL_plugin **) find_rendezvous_v
Yesterday I suggested that we should redesign the PL plugin patch:
http://archives.postgresql.org/pgsql-patches/2006-07/msg00291.php
in view of the recently-committed patch to add initialization/
finalization support for all dynamic libraries loaded into the backend:
http://archives.postgresql.org/
12 matches
Mail list logo
