Re: Feature patch 1 for plperl [PATCH]

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 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.

regards, tom lane