On Sat, Sep 19, 2009 at 11:43:26PM -0400, Tom Lane wrote:
> Robert Haas <robertmh...@gmail.com> writes:
> > On Sat, Sep 19, 2009 at 3:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> "Tim Bunce" <tim.bu...@pobox.com> writes:
> >>> The plperl implementation doesn't call perl_destruct() during server
> >>> shutdown.
> >>
> >> Who cares? �The process is going away anyway.
>
> > END {} blocks can execute arbitrary code. Perl users will expect them
> > to be executed.
>
> [ shrug... ] As a database geek I find the lack of guarantees about
> that to be entirely unsatisfying. What exactly are you going to put
> in that block? If it's actually important, are you going to trust
> a mechanism that doesn't have any crash safeness?
Can you expand on what you mean by 'guarantees' and 'crash safeness'?
I my particular case I'm trying to enable Devel::NYTProf, the perl
source code performance profiler, to profile PL/Perl code.
See http://www.slideshare.net/Tim.Bunce/develnytprof-200907
(starting
NYTProf uses an END block to finish up the profile and write final
details to the data file. One of the first problems I ran into was that
Postgres was executing the END block before the first plperl sub was
even executed. Very counter intuitive. Since NYTProf is implemented in C
(XS) I've worked around that problem by adding an option to enable
PL_exit_flags |= PERL_EXIT_DESTRUCT_END.
But because postgres doesn't call perl_destruct() the problem has just
moved from END blocks being called too early to END blocks not being
called at all. The effect is that the profile data file is unterminated
and so corrupt and unusable.
To finish the profiling users currently have to execute a SQL statement
to trigger a plperl sub that calls an NYTProf sub that finializes the
profile. Ideally I'd like users to be able to finish the profiling
cleanly with a shutdown (to then restart with profiling disabled).
Calling perl_destruct() during shutdown would fix that.
Tim.
p.s. As a random data point, google code search finds about 7000
perl modules containing an END block:
http://www.google.com/codesearch?as_q=%5EEND%5C+%7B&btnG=Search+Code&hl=en&as_lang=perlas_filename=%5C.pm%24&as_case=y
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
