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

From Robert Haas
Subject Re: BUG #5066: plperl issues with perl_destruct() and END blocks
Date
Msg-id 603c8f070909220637g16f58ca1l14d105b80e8711ae@mail.gmail.com
Whole thread Raw
In response to Re: BUG #5066: plperl issues with perl_destruct() and END blocks  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #5066: plperl issues with perl_destruct() and END blocks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Mon, Sep 21, 2009 at 7:30 PM, Tom Lane <tgl@sss.pgh.pa.us> 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. =A0Is 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? =A0What 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. =A0If you do something like
> creating threads inside plperl, we're going to give you the raspberry
> when you complain about it breaking. =A0END blocks can perfectly well
> go into the same category.

If the changes are simple, as Tim seems to believe, exactly what do we
lose by doing this?

...Robert

pgsql-bugs by date:

Previous
From: "Amit Khandekar"
Date:
Subject: BUG #5072: User trying to drop an internally dependent object crashes server
Next
From: Tom Lane
Date:
Subject: Re: BUG #5066: plperl issues with perl_destruct() and END blocks