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

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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