Обсуждение: 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 wayto 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 modulesthat have custom GUCs, potentially a security issue? The addition of new PL/Perl custom GUCs notwithstanding, it sureseems 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@postgresql.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