GUC failure on exception

Tim Bunce just showed me the following oddity:

andrew=# SET SESSION plperl.use_strict = on;
SET
andrew=# SHOW plperl.use_strict;
plperl.use_strict
-------------------
on
(1 row)

andrew=# DO $$ elog(ERROR,"error") $$ language plperl;
ERROR: error at line 1.
CONTEXT: PL/Perl anonymous code block
andrew=# SHOW plperl.use_strict;
plperl.use_strict
-------------------
off
(1 row)

Somehow we have lost the setting, because the first use of plperl, which
called the plperl init code, failed.

It appears that whatever rolls it back forgets to put the GUC setting
back as it was, and now it's lost, which is pretty darn ugly. And you
can now run code which fails the 'strict' tests.

If anyone has a quick idea about how to fix that would be nice.
Otherwise I'll try to delve into it as time permits.

cheers

andrew

Andrew Dunstan wrote:
>
> Tim Bunce just showed me the following oddity:
>
> andrew=# SET SESSION plperl.use_strict = on;
> SET
> andrew=# SHOW plperl.use_strict;
> plperl.use_strict
> -------------------
> on
> (1 row)
>
> andrew=# DO $$ elog(ERROR,"error") $$ language plperl;
> ERROR: error at line 1.
> CONTEXT: PL/Perl anonymous code block
> andrew=# SHOW plperl.use_strict;
> plperl.use_strict
> -------------------
> off
> (1 row)
>
>
> Somehow we have lost the setting, because the first use of plperl,
> which called the plperl init code, failed.
>
> It appears that whatever rolls it back forgets to put the GUC setting
> back as it was, and now it's lost, which is pretty darn ugly. And you
> can now run code which fails the 'strict' tests.
>
>

The first thing I think we need to do is move the GUC processing code
out of _PG_init() and into plperl_init_interp(), protected by a flag to
make sure it's only called successfully once. I'm trying to work out a
neat way to put the value back if there is an exception, but it's a bit
ugly.

cheers

andrew

On Jan 19, 2010, at 9:26 PM, Andrew Dunstan wrote:

> The first thing I think we need to do is move the GUC processing code out of _PG_init() and into plperl_init_interp(), protected by a flag to make sure it's only called successfully once. I'm trying to work out a neat way to put the value back if there is an exception, but it's a bit ugly.

Will this solve the underlying bug in custom GUCs? I'm assuming there is such a bug. Won't this be an issue for other modules that have custom GUCs, potentially a security issue? The addition of new PL/Perl custom GUCs notwithstanding, it sure seems like a potential security vulnerability such as this should be addressed ASAP.

Who knows this stuff?

Best,

David

Did this ever get turned into a formal bug report with a number?

Tim.

On Thu, Jan 14, 2010 at 07:39:09PM -0500, Andrew Dunstan wrote:
>
> Tim Bunce just showed me the following oddity:
>
> andrew=# SET SESSION plperl.use_strict = on;
> SET
> andrew=# SHOW plperl.use_strict;
> plperl.use_strict
> -------------------
> on
> (1 row)
>
> andrew=# DO $$ elog(ERROR,"error") $$ language plperl;
> ERROR: error at line 1.
> CONTEXT: PL/Perl anonymous code block
> andrew=# SHOW plperl.use_strict;
> plperl.use_strict
> -------------------
> off
> (1 row)
>
>
> Somehow we have lost the setting, because the first use of plperl,
> which called the plperl init code, failed.
>
> It appears that whatever rolls it back forgets to put the GUC
> setting back as it was, and now it's lost, which is pretty darn
> ugly. And you can now run code which fails the 'strict' tests.
>
> If anyone has a quick idea about how to fix that would be nice.
> Otherwise I'll try to delve into it as time permits.
>
> cheers
>
> andrew
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Tim Bunce wrote:
> Did this ever get turned into a formal bug report with a number?
>

No, and nobody seemed to care much about the poroblem :-( Maybe I will
get a chance to do something about it during the next few weeks,
although I am currently busier than a one legged man in a butt-kicking
contest.

The GUC code is a mess w.r.t. this, and I didn't come up with a nice
solution. Everything I thought of to try to fix it was so unspeakably
ugly and fragile that I didn't even bother bringing it up.

The one thing we could possibly usefully do for plperl is to move the
GUC setup code from _PG_init() to plperl_init_interp(), protected by a
flag to make sure it only runs once. But most of the problem lies
outside plperl's code.

But by all means file a bug report, so we don't lose track of it.

cheers

andrew