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

"korryd(at)enterprisedb(dot)com" <korryd(at)enterprisedb(dot)com> writes:
>> The other, probably more controversial bit of functionality is that there
>> needs to be a way to cause a backend to load a PL plugin shared library
>> without any cooperation from the connected client application.

> Ok, but you should know that the PL/pgSQL debugger already handles this
> without any cooperation from the client.
> Loading the PL debugger means that your backend becomes debuggable, not
> that it actually starts debugging.

Right, the question is how do you load it, assuming that you do not want
to enable it for every single session in your database.

> So, other than the (negligible) performance penalty, its safe to load
> the debugger plugin into every backend. (If you've loaded the debugger,
> the extra overhead is a single, lightweight-lock protected,
> shared-memory hash lookup for each PL function invocation).

I'm not sure you'll be able to convince everyone that the penalty is so
negligible --- any high-rate access to shared memory is potentially very
expensive, see nearby threads for examples. Even if this is affordable
for the debugger, what of more-invasive plugins such as the performance
monitor? I think a credible general-purpose plugin design has to
address the problem of enabling plugins on-the-fly.

> I don't think it could crash because there's no way to unload a plugin
> (there is no UNLOAD statement, is there?).

What we actually have at the moment is that you can LOAD a library
again, which causes an unload of the prior version and then loading the
new. I suppose this feature was intended to speed library development by
letting you recompile and then update into your existing backend session.
Not sure how many people are using it, but it's there ...

> Which reminds me, you haven't proposed a way to unload a shared-library.

This depends on the semantics we want to assign to
backend_shared_libraries --- I could imagine defining it as "if you
remove an entry from the value then we'll unload that library".

> How about a combination of plan A and plan B? Make
> backend_load_libraries a USERSET variable, but you can't *add* libraries
> outside of $libdir/plugins/ unless you are a superuser.

Not sure how easy that is (ie, can we track which part of the list came
from where), but if doable it'd be OK with me. We might have to split
it into two list variables to make it work, and I'm not sure it's worth
the complication.

>> BTW, is anyone up for renaming the existing "preload_libraries" variable
>> to "postmaster_load_libraries"? This would be more symmetrical with
>> "backend_load_libraries", and so perhaps clearer about which does what

> Makes sense to me, of course that breaks existing postgresql.conf files.

We already broke them by removing the init-function name...

> Do you want me to do any of this coding?

Up to you --- I can do it if you don't want to.

regards, tom lane