Re: BUG #5066: plperl issues with perl_destruct() and END blocks

On Mon, Sep 21, 2009 at 07:30:51PM -0400, Tom Lane wrote:
> David Fetter <david@fetter.org> writes:
> > On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote:
> >>> With connection poolers, backends can last quite awhile.  Is it OK
> >>> for the END block to run hours after the rest of the code?

Yes.

> >> This is an interesting point -- should END blocks be called on
> >> DISCARD ALL?
>
> > ENOCLUE
>
> And in the same vein, should they be called inside a transaction,
> or not?  What if they fail?

As I said in the original ticket, I'd be quite happy for plperl END
blocks to have no access to postgres at all, other than warnings going
to the log. The spi_* functions could return an error if postgres is
being shutdown (perhaps they already would if perl_destruct is called
late in the shutdown sequence). So transactions are mute.
Also, perl_destruct() will catch any exceptions from END blocks.

> I don't see any reason whatsoever that we couldn't just document this
> as a Perl feature not supported in plperl.  If you do something like
> creating threads inside plperl, we're going to give you the raspberry
> when you complain about it breaking.  END blocks can perfectly well
> go into the same category.

Returning to my original use case, the NYTProf profiler needs END blocks
to work otherwise the generated profile data will be corrupt.

I don't see any reason not to add PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
to plperl_init_interp(), and for perl_destruct() to be called late in
the shutdown sequence.

Tim.