Re: BUG #5066: plperl issues with perl_destruct() and END blocks

On Tue, Sep 22, 2009 at 10:13 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> If the changes are simple, as Tim seems to believe, exactly what do we
>> lose by doing this?
>
> It's not simple.  There are any number of issues that Tim has not
> addressed.  The most obvious: *his* use case might not require database
> access in an END block, but that doesn't mean the next complainant won't
> want it.

Well, that's a reason why you might have to say no to the next
complainant, but not necessarily the current one.

> Another point that comes to mind is shared_preload_libraries: if plperl
> is loaded once in the postmaster, it seems entirely likely that the same
> END block would be executed in multiple backends after having been
> loaded only once.  Again, while that might be okay for his particular
> use-case, it seems horribly dangerous for anything else.

Regular perl has the same problem, so any perl modules that are
counting on any other behavior are already broken.

$ perl -e 'fork(); END { print "hi\n" }'
hi
hi

> (The shared_preload_libraries case also destroys the most obvious
> implementation path, ie having plperl add an on_proc_exit callback
> at _PG_init time...)

Can't comment on that.

> But my basic objection is that a PL is a device for executing code in
> functions.  It has no business being used to cause "action at a
> distance" outside of those functions.  If we go down this path we are
> going to regret it.

I agree with that concern, but if this were already implemented the
way that Tim wants it, we would be unlikely to change it to the way
that it is now on that basis. In practice, I don't think anyone uses
END {} blocks for anything terribly elaborate, because it falls over.
They are however useful for things like dumping debugs or profiling
statistics, and I don't see much reason to prevent those sorts of
uses. I also think that to some degree the horse has already left the
barn on this one: if the Perl interpreter isn't being destroyed until
backend exit, that implies that you can ALREADY do all kinds of
horrible things, like setting global variables and reading them back
later. What happens if you call fork(), or pthread_create(), or
modify %SIG?

...Robert