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

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
Date: 2006-08-09 22:43:06
Message-ID: 1155163386.24313.79.camel@sakai.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

> 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 have no problem with your solution - I think its a very nice design.

>
> > 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 ...

Right, but you still end up with a plugin loaded afterwards so no crash
(of course you could do something stupid like load a new plugin with the
same name that isn't really a plugin).

> > 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".

That's what I was thinking too.

> > 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.

The GUC assign hook would parse through backend_load_libraries...

for each library,
{
if ( the library is already loaded )
{
// it's not a new library, doesn't matter where it lives,
doesn't matter if we're a superuser

load( library)
}
else
{
// it's a new entry in backed_load_libraries

if( library lives in $libdir/plugins )
load( library )
else
{
if( is_superuser())
load( library )
else
throw an error
}
}
}

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

Right...

> > Do you want me to do any of this coding?
>
> Up to you --- I can do it if you don't want to.

I'll take a stab at it... thanks for your help so far.

-- 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 Andrej Ricnik-Bay 2006-08-09 22:56:11 Re: new job
Previous Message Luke Lonergan 2006-08-09 22:42:13 Re: new job

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-08-09 23:05:46 Re: Plugins redux (was Re: [PATCHES] PL instrumentation
Previous Message Tom Lane 2006-08-09 22:04:49 Re: Plugins redux (was Re: [PATCHES] PL instrumentation plugin