Skip site navigation (1) Skip section navigation (2)

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

From: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Fetter <david(at)fetter(dot)org>,Alvaro Herrera <alvherre(at)commandprompt(dot)com>,Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>,Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5066: plperl issues with perl_destruct() and ENDblocks
Date: 2009-09-22 08:39:00
Message-ID: 20090922083900.GB4100@timac.local (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Mon, Sep 21, 2009 at 07:30:51PM -0400, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)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?


> >> This is an interesting point -- should END blocks be called on
> 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.


In response to

pgsql-bugs by date

Next:From: Tim BowdenDate: 2009-09-22 09:32:07
Subject: Re: Databse installation problem
Previous:From: Annita VenetiDate: 2009-09-22 08:30:29
Subject: Re: BUG #5063: MS Access crashes by quiting after linking tables with PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group