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

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
Date: 2006-08-09 23:05:46
Message-ID: 1903.1155164746@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:
>>> (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.

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

That is only true given careful design and implementation of the
hooks. Right now for instance I think it's possible to crash the
backend by doing "LOAD 'plpgsql'" multiple times, because it hooks
into CallXactCallbacks and doesn't unhook. (Now that we have PG_fini
it should be possible to fix that...) Doesn't seem to crash
on the HPUX machine I just tried it on, but maybe HPUX is weird and
doesn't actually remove the old library from the address space?

Anyway I disagree with your proposal to let unprivileged users re-LOAD
random libraries. If they've not been modified to have clean unload
semantics this isn't safe.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2006-08-09 23:17:10 Win32 max connections bug (causing crashes)
Previous Message Andrej Ricnik-Bay 2006-08-09 22:56:11 Re: new job

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-08-10 00:44:34 Re: Fix statement timing display
Previous Message korryd@enterprisedb.com 2006-08-09 22:43:06 Re: Plugins redux (was Re: [PATCHES] PL instrumentation