From: | Robert Haas <robertmhaas(at)gmail(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>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5066: plperl issues with perl_destruct() and END blocks |
Date: | 2009-09-22 13:37:10 |
Message-ID: | 603c8f070909220637g16f58ca1l14d105b80e8711ae@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Sep 21, 2009 at 7:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
>>> 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.
If the changes are simple, as Tim seems to believe, exactly what do we
lose by doing this?
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | nanda gopal | 2009-09-22 14:10:17 | Requesting the Revision History |
Previous Message | Amit Khandekar | 2009-09-22 12:16:58 | BUG #5072: User trying to drop an internally dependent object crashes server |