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 plugin |
Date: | 2006-08-10 15:55:19 |
Message-ID: | 1155225319.24313.95.camel@sakai.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> 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 only once, and there are other possible
> uses for it besides PL plugins.
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 that time, we know whether
we are a superuser and we have processed all GUC options.
Also, should we create an on_proc_exit() handler that would unload all
dynamic libraries (specifically to call the _PG_fini() functions)?
-- Korry
--
Korry Douglas korryd(at)enterprisedb(dot)com
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-10 16:05:06 | Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin |
Previous Message | William ZHANG | 2006-08-10 15:53:11 | Re: Win32 max connections bug (causing crashes) |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-10 16:05:06 | Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin |
Previous Message | Jonah H. Harris | 2006-08-10 15:52:47 | Re: Updated INSERT/UPDATE RETURNING |