Re: BUG #5066: plperl issues with perl_destruct() and END blocks - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #5066: plperl issues with perl_destruct() and END blocks
Date
Msg-id 28109.1253575851@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #5066: plperl issues with perl_destruct() and END blocks  (David Fetter <david@fetter.org>)
Responses Re: BUG #5066: plperl issues with perl_destruct() and END blocks  (Tim Bunce <Tim.Bunce@pobox.com>)
Re: BUG #5066: plperl issues with perl_destruct() and END blocks  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-bugs
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?
>>
>> 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?

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.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Matt Taylor
Date:
Subject: Re: BUG #5063: MS Access crashes by quiting after linking tables with PostgreSQL
Next
From: ""
Date:
Subject: BUG #5071: abbrev() bug with IPv6