On Sat, Dec 05, 2009 at 01:21:22AM -0500, Tom Lane wrote: > "David E. Wheeler" <da...@kineticode.com> writes: > > Tom, what's your objection to Shlib load time being user-visible? > > It's not really designed to be user-visible. Let me give you just > two examples: > > * We call a plperl function for the first time in a session, causing > plperl.so to be loaded. Later the transaction fails and is rolled > back. If loading plperl.so caused some user-visible things to happen, > should those be rolled back?
No. Establishing initial state, no matter how that's triggered, is not part of a transaction. > * We call a plperl function for the first time in a session, causing > plperl.so to be loaded. This happens in the context of a superuser > calling a non-superuser security definer function, or perhaps vice > versa. Whose permissions apply to whatever the on_load code tries > to do? (Hint: every answer is wrong.) I'll modify the patch to disable the SPI functions during initialization (both on_perl_init and on_(un)trusted_init). Would that address your concerns? > That doesn't even begin to cover the problems with allowing any of > this to happen inside the postmaster. Recall that the postmaster > does not have any database access. Furthermore, it is a very long > established reliability principle around here that the postmaster > process should do as little as possible, because every thing that it > does creates another opportunity to have a nonrecoverable failure. > The postmaster can recover if a child crashes, but the other way > round, not so much. I hope the combination of disabling the SPI functions during initialization, and documenting the risks of combining on_perl_init and shared_preload_libraries, is sufficient. Tim. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
