Re: Add on_perl_init and proper destruction to plperl [PATCH]

On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
> Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> writes:
> > On Wed, Jan 27, 2010 at 12:46:42AM -0700, Alex Hunsaker wrote:
> >> FWIW the atexit scares me to.
>
> > In what way, specifically?
>
> It runs too late, and too unpredictably, during the shutdown sequence.
> (In particular note that shutdown itself might be fired as an atexit
> callback, a move forced on us by exactly the sort of random user code
> that you want to add more of. It's not clear whether a Perl-added
> atexit would fire before or after that.)

man atexit says "Functions so registered are called in reverse order".
Since the plperl atexit is called only when a plperl SP or DO is
executed it would fire before any atexit() registered during startup.

The timing and predictability shouldn't be a significant concern if the
plperl subsystem can't interact with the rest of the backend - which is
the intent.

> > I understand concerns about interacting with the database, so the
> > patch ensures that any use of spi functions throws an exception.
>
> That assuages my fears to only a tiny degree. SPI is not the only
> possible connection between perl code and the rest of the backend.

Could you give me some examples of others?

> Indeed, AFAICS the major *point* of these additions is to allow people
> to insert unknown other functionality that is likely to interact
> with the rest of the backend; a prospect that doesn't make me feel
> better about it.

The major point is *not at all* to allow people to interact with the
rest of the backend. I'm specifically trying to limit that.
The major point is simply to allow perl code to clean itself up properly.

> > Specifically, how is code that starts executing at the end of a session
> > different in risk to code that starts executing before the end of a session?
>
> If it runs before the shutdown sequence starts, we know we have a
> functioning backend. Once shutdown starts, it's unknown and mostly
> untested exactly what subsystems will still work and which won't.
> Injecting arbitrary user-written code into an unspecified point in
> that sequence is not a recipe for good results.

The plperl subsystem is isolated from, and can't interact with, the rest
of the backend during shutdown.
Can you give me examples where that's not the case?

> Lastly, an atexit trigger will still fire during FATAL or PANIC aborts,
> which scares me even more. When the house is already afire, it's
> not prudent to politely let user-written perl code do whatever it wants
> before you get the heck out of there.

Again, that point rests on your underlying concern about interaction
between plperl and the rest of the backend. Examples?

Is there some way for plperl.c to detect a FATAL or PANIC abort?
If so, or if one could be added, then we could skip the END code in
those circumstances.

I don't really want to add more GUCs, but perhaps controlling END
block execution via a plperl.destroy_end=bool (default false) would
help address your concerns.

Tim.