Skip site navigation (1) Skip section navigation (2)

Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, "David E(dot) Wheeler" <david(dot)wheeler(at)pgexperts(dot)com>
Subject: Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
Date: 2010-02-25 03:00:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Wed, Feb 24, 2010 at 19:17, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
> On Tue, Feb 23, 2010 at 15:23, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)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):


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 ----

+ 	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;

  	if (count != 1)
*** 1697,1702 **** compile_plperl_function(Oid fn_oid, bool is_trigger)
--- 1704,1721 ----


+ 		/************************************************************
+ 		 * 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,
+ 				 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,

In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2010-02-25 03:19:30
Subject: Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
Previous:From: Alex HunsakerDate: 2010-02-25 02:17:52
Subject: Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group