Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
