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

On Jan 27, 2010, at 3:11 PM, Tom Lane wrote:

> You still aren't letting go of the notion that Perl could only affect
> the rest of the backend via SPI. The point I'm trying to impress on you
> is that there are any number of other possible pathways, and that Perl's
> historical assumption that it owns all resources of the process make
> those pathways a nontrivial hazard. Anything that Perl does to libc
> state, open file handles, etc etc carries a high risk of breaking the
> backend.

As could any other code that executes then, including C libraries installed from pgFoundry and loaded by a DBA.

> Now it is certainly true that any such hazards can be created just from
> use of plperlu (we hope only plperlu, and not plperl ...) today,
> without any use of the proposed additional features. What is bothering
> me about these features is that their entire reason for existence is to
> encourage people to use parts of Perl that have time-extended effects on
> the process state.

Well, mainly it's to avoid the overhead of loading the code except at startup.

> That means that (a) the probability of problems goes
> up substantially,

Why? Arbitrary code can already execute at start time. Is Perl special somehow?

> and (b) our ability to fix such problems goes down
> substantially.

Why is it your problem?

> Right now, the canonical approach to trying to undo
> anything bad Perl does is to save/restore process state around a plperl
> call. If we're trying to support usages in which Perl has time-extended
> effects on process state, that solution goes out the window, and we have
> to think of some other way to coexist with Perl. (Where, I note,
> "coexist" means "Perl does what it damn pleases and we have to pick up
> the pieces" --- we're not likely to get any cooperation on limiting
> damage from that side. Nobody even suggested that we treat stomping on
> setlocale state as a Perl bug, for example, rather than a fact of life
> that we just had to work around however we could.)

How is that different from any other code that gets loaded when the server starts, exactly?

Do, however, feel free to report Perl bugs. Just run `perlbug`.

> So the real bottom line here is that I foresee this patch as being
> destabilizing and requiring us to put large amounts of time into
> figuring out workarounds for whatever creative things people decide to
> try to do with Perl. I'd feel better about it if I thought that we
> could get away with a policy of "if it breaks it's your problem", but
> I do not think that will fly from a PR standpoint. It hasn't in the
> past.

mod_perl has for many years. Provide lots of caveats in the documentation. Point users to it when they write in about a problem.

Truth is, the vast majority of Perl modules are pretty well-behaved. I sincerely doubt you'd hear much complaint. Have the Apache guys had to take any special steps to protect httpd from mod_perl?

Best,

David