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.
