Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin
Date
Msg-id 16230.1155225906@sss.pgh.pa.us
Whole thread Raw
In response to Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin  ("korryd@enterprisedb.com" <korryd@enterprisedb.com>)
Responses Re: Plugins redux (was Re: [PATCHES] PL instrumentation
List pgsql-hackers
"korryd@enterprisedb.com" <korryd@enterprisedb.com> 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 that time, we know whether
> we are a superuser and we have processed all GUC options.

Sounds fine.

> 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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "korryd@enterprisedb.com"
Date:
Subject: Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin
Next
From: Tom Lane
Date:
Subject: Re: Win32 max connections bug (causing crashes)