Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
От | Alex Hunsaker |
---|---|
Тема | Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0) |
Дата | |
Msg-id | 34d269d41002241900r6a451349ybbfd41dd1e7cbc74@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0) (Alex Hunsaker <badalex@gmail.com>) |
Ответы |
Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
|
Список | pgsql-bugs |
On Wed, Feb 24, 2010 at 19:17, Alex Hunsaker <badalex@gmail.com> wrote: > On Tue, Feb 23, 2010 at 15:23, Tim Bunce <Tim.Bunce@pobox.com> wrote: > >> I believe (but haven't yet confirmed) that the problem here is recursion. >> This affects all versions of PostgreSQL. > Ill keep digging. Ok I understand now, basically the problem is (as Tim also described elsewhere): postgres->plperl_call_perl_func->SPI->postgres->plperl_create_sub On that last call to plperl_create_sub we are still executing under Safe (as its the same interpreter). And so it fails when it tries to compile a new sub. ISTM the easiest and safest fix would be to not allow recursive plperl creations. You could still call plperl functions within functions, just not if they are not defined. This limitation really blows so im hoping someone else has a better idea? Alternately we could also break out of the safe, compile the sub and then go back to it as Tim suggested up-thread. I think this could work as long as its not to nasty (which Tim does not seem to think it would be). Thoughts? Better Ideas? [ patch against 8.3/8.4 ] ---- *** a/src/pl/plperl/plperl.c --- b/src/pl/plperl/plperl.c *************** *** 126,131 **** static HTAB *plperl_proc_hash = NULL; --- 126,132 ---- static HTAB *plperl_query_hash = NULL; static bool plperl_use_strict = false; + static bool plperl_executing = false; /* this is saved and restored by plperl_call_handler */ static plperl_call_data *current_call_data = NULL; *************** *** 1117,1125 **** plperl_call_perl_func(plperl_proc_desc *desc, FunctionCallInfo fcinfo) --- 1118,1132 ---- } PUTBACK; + if (desc->lanpltrusted) + plperl_executing = true; + /* Do NOT use G_KEEPERR here */ count = perl_call_sv(desc->reference, G_SCALAR | G_EVAL); + if (desc->lanpltrusted) + plperl_executing = false; + SPAGAIN; if (count != 1) *************** *** 1697,1702 **** compile_plperl_function(Oid fn_oid, bool is_trigger) --- 1704,1721 ---- check_interp(prodesc->lanpltrusted); + /************************************************************ + * Dont let us recursively create a plperl function from a plperl function + * as plperl_create_sub gets called we are running under Safe and fails. + * TODO: We could break out of the safe via Safe::HOLE or some such. + ************************************************************/ + if (prodesc->lanpltrusted && plperl_executing) + ereport(ERROR, + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), + errmsg("could not create plperl function \"%s\"", prodesc->proname), + errdetail("plperl functions can not recursivley define other plperl functions"), + errhint("try calling the function first"))); + prodesc->reference = plperl_create_sub(prodesc->proname, proc_source, prodesc->lanpltrusted);
В списке pgsql-bugs по дате отправления:
Предыдущее
От: Alex HunsakerДата:
Сообщение: Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
Следующее
От: Tom LaneДата:
Сообщение: Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)