Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>
>> On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>>> What happens when the supplied code
>>> has errors, takes an unreasonable amount of time to run, does something
>>> unsafe, depends on the backend not being in an error state already, etc
>>> etc?
>>>
>
>
>> Same thing that happens when you put something stupid into
>> shared_preload_libraries - you destabilize your database cluster and
>> the world blows up.
>>
>
> shared_preload_libraries is under the sole control of the DBA, though.
> What distresses me about this is the exposure to ordinary users.
> In particular, that casual little "atexit" addition appears to mean
> that *unprivileged* users can break normal functioning of the database,
> eg by delaying or even preventing shutdown. That's a security hole of
> the first magnitude. Trying to execute SPI code there could make things
> even more fun.
>
I suspect that could be inhibited at least.
> I also still don't care for the whole concept of on_init code from a
> theoretical standpoint: as I said before, loading of the plperl shared
> library should not be a semantically significant event from the user's
> viewpoint. If these GUCs were PGC_POSTMASTER it wouldn't be so bad, but
> Tim still seems to want them to be settable inside an individual session
> before the library is loaded, which makes the loading extremely visible.
> As an example, if people were using such functionality then the DBA
> couldn't start preloading plperl for performance without breaking
> behavior that some of his users might be depending on.
>
>
>
Well, I think the proposed plperl.on_perl_init setting could be
PGC_POSTMASTER, as I previously commented.
The other settings are intended to be used on interpreter start, AIUI.
Maybe we need to explore the use cases more.
If we made plperl.on_perl_init PGC_POSTMASTER and the other two
PGC_SUSET would that alloy your concerns?
cheers
andrew