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