Re: Add on_perl_init and proper destruction to plperl [PATCH]
Alex Hunsaker <badalex@gmail.com>
From: Alex Hunsaker <badalex@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Tim Bunce <Tim.Bunce@pobox.com>, pgsql-hackers@postgresql.org
Date: 2010-01-27T07:46:42Z
Lists: 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?