Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin

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

In response to

Responses

Browse pgsql-hackers by date

  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)

Browse pgsql-patches by date

  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