"[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
"[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.
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/
