[GENERAL] Small patch for PL/Perl Misbehavior with Runtime Error Reporting

John Worsley <lx@openvein.com> writes:

I just stumbled across this peculiarity in PL/Perl today writing a method
to invoke Perl Regexes from a function: if a run-time error is raised in
an otherwise good function, the function will never run correctly again
until the connection to the database is reset. I poked around in the code
and it appears that it's because when elog() raises the ERROR, it doesn't
first take action to erase the system error message ($@) and consequently
every subsequent run has an error raised, even if it runs successfully.

That seems a little weird. Does Perl really expect people to do that
(ie, is it a documented part of some API)? I wonder whether there is
some other action that we're supposed to take instead, but are
missing...

src/pl/plperl/plperl.c:
443c443,445
< elog(ERROR, "plperl: error from function: %s", SvPV(ERRSV, PL_na));
---

elog(NOTICE, "plperl: error from function: %s", SvPV(ERRSV, PL_na));
sv_setpv(perl_get_sv("@",FALSE),"");
elog(ERROR, "plperl: error was fatal.");

If this is what we'd have to do, I think a better way would be

perlerrmsg = pstrdup(SvPV(ERRSV, PL_na));
sv_setpv(perl_get_sv("@",FALSE),"");
elog(ERROR, "plperl: error from function: %s", perlerrmsg);

Splitting the ERROR into a NOTICE with the useful info and an ERROR
without any isn't real good, because the NOTICE could get dropped on the
floor (either because of min_message_level or a client that just plain
loses notices).

regards, tom lane

On Thu, 3 Oct 2002, Tom Lane wrote:

That seems a little weird. Does Perl really expect people to do that
(ie, is it a documented part of some API)? I wonder whether there is
some other action that we're supposed to take instead, but are
missing...

Not that I know of: clearing out the $@ variable manually was just my way
of getting around the problem in practice. I think the underlying issue
may be tied to the fact that it's running a function generated within a
Safe Module, but I'm not enough of a Perl Guru to say anything more
decisive than that.

If this is what we'd have to do, I think a better way would be

perlerrmsg = pstrdup(SvPV(ERRSV, PL_na));
sv_setpv(perl_get_sv("@",FALSE),"");
elog(ERROR, "plperl: error from function: %s", perlerrmsg);
Splitting the ERROR into a NOTICE with the useful info and an ERROR
without any isn't real good, because the NOTICE could get dropped on the
floor (either because of min_message_level or a client that just plain
loses notices).

Yeah, that's a cleaner solution. I take it anything pstrdup'd by
PostgreSQL gets freed automatically by the backend? (I wasn't familiar
enough with the backend to know how to ask for memory confident in the
understanding that it would at some point be freed. ;)

Jw.
--
John Worsley - lx@openvein.com
http://www.openvein.com/

John Worsley <lx@openvein.com> writes:

Yeah, that's a cleaner solution. I take it anything pstrdup'd by
PostgreSQL gets freed automatically by the backend?

Pretty much. The only situation where it wouldn't be is if
CurrentMemoryContext is pointing at TopMemoryContext or another
long-lived context --- but we are *very* chary about how much code we
allow to run with such a setting. User-definable functions can safely
assume that palloc'd space will live only long enough for them to return
something to their caller in it.

regards, tom lane

Did we ever address this plperl issue? I see the code unchanged in CVS.

---------------------------------------------------------------------------

Tom Lane wrote:

John Worsley <lx@openvein.com> writes:

I just stumbled across this peculiarity in PL/Perl today writing a method
to invoke Perl Regexes from a function: if a run-time error is raised in
an otherwise good function, the function will never run correctly again
until the connection to the database is reset. I poked around in the code
and it appears that it's because when elog() raises the ERROR, it doesn't
first take action to erase the system error message ($@) and consequently
every subsequent run has an error raised, even if it runs successfully.

That seems a little weird. Does Perl really expect people to do that
(ie, is it a documented part of some API)? I wonder whether there is
some other action that we're supposed to take instead, but are
missing...

src/pl/plperl/plperl.c:
443c443,445
< elog(ERROR, "plperl: error from function: %s", SvPV(ERRSV, PL_na));
---

elog(NOTICE, "plperl: error from function: %s", SvPV(ERRSV, PL_na));
sv_setpv(perl_get_sv("@",FALSE),"");
elog(ERROR, "plperl: error was fatal.");

If this is what we'd have to do, I think a better way would be

perlerrmsg = pstrdup(SvPV(ERRSV, PL_na));
sv_setpv(perl_get_sv("@",FALSE),"");
elog(ERROR, "plperl: error from function: %s", perlerrmsg);

Splitting the ERROR into a NOTICE with the useful info and an ERROR
without any isn't real good, because the NOTICE could get dropped on the
floor (either because of min_message_level or a client that just plain
loses notices).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Did we ever address this plperl issue? I see the code unchanged in CVS.

It's fixed, although not in the way proposed in that patch.

regards, tom lane