Re: Add on_perl_init and proper destruction to plperl [PATCH]
От | Alex Hunsaker |
---|---|
Тема | Re: Add on_perl_init and proper destruction to plperl [PATCH] |
Дата | |
Msg-id | 34d269d41001262346m42712117m82341f05675d9ede@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add on_perl_init and proper destruction to plperl [PATCH] (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add on_perl_init and proper destruction to plperl
[PATCH]
|
Список | pgsql-hackers |
On Tue, Jan 26, 2010 at 23:14, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Tim Bunce wrote: >>> - Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP) >>> SPI functions are not available when the code is run. >>> >>> - Added normal interpreter destruction behaviour >>> END blocks, if any, are run then objects are >>> destroyed, calling their DESTROY methods, if any. >>> SPI functions will die if called at this time. > >> So, are there still objections to applying this patch? > > Yes. FWIW the atexit scares me to. I was thinking a good workaround perhaps would be to provide a function that destroys the interpreter (so that the END blocks get called). Tim would that work OK ? If we are still worried about that hanging we can probably do something hacky with alarm() and/or signals... Maybe a good solid use case will help figure this out? Im assuming the current one is to profile plperl functions and dump a prof file in /tmp/ or some such (which happens at END time). Or did I miss the use case in one of the other threads?
В списке pgsql-hackers по дате отправления: