From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "korryd(at)enterprisedb(dot)com" <korryd(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin |
Date: | 2006-08-10 16:05:06 |
Message-ID: | 16230.1155225906@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
"korryd(at)enterprisedb(dot)com" <korryd(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-10 16:10:01 | Re: Win32 max connections bug (causing crashes) |
Previous Message | korryd@enterprisedb.com | 2006-08-10 15:55:19 | Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin |
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2006-08-10 16:53:10 | Re: [pstehule@ilikethis.cz: plperl enhancing return possibilities] |
Previous Message | korryd@enterprisedb.com | 2006-08-10 15:55:19 | Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin |