On Mon, Sep 21, 2009 at 07:30:51PM -0400, Tom Lane wrote: > David Fetter <da...@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. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
