On Jan 27, 2010, at 1:27 PM, Tim Bunce wrote: > Okay. I could change the callback code to ignore calls if > proc_exit_inprogress is false. So an abnormal shutdown via exit() > wouldn't involve plperl at all. (Alternatively I could use use > on_proc_exit() instead of atexit() to register the callback.)
Given Tom's hesitace about atexit(), perhaps that would be best. > Neither of those relate to the actions of perl source code. > To address that, instead of calling perl_destruct() to perform a > complete destruction I could just execute END blocks and object > destructors. That would avoid executing any system-level actions. Does perl_destruct() execute system-level actions, then? If so, then it seems prudent to either audit such actions or, as you say, call destructors directly. > Do you have any examples of how a user could write code in a plperl END > block that would interact with the rest of the backend? I appreciate you taking the time to look at ways to address the issues Tom has raised, Tim. Good on you. There is so much benefit to this level of interaction, as shown by the success of mod_perl and other forking environments that support pre-loading code, that I think it'd be extremely valuable to get these features in 9.0. They really allow Perl to be a first-class PL in a way that it wasn't before. So if there is no way other than SPI for Perl code to interact with the backend, and system-level actions in Perl itself are disabled, it seems to me that the major issues are addressed. Am I wrong, Tom? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
