On Sat, Dec 05, 2009 at 01:21:22AM -0500, Tom Lane wrote:
> "David E. Wheeler" <david@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.