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

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

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 (view raw or flat)
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

In response to

Responses

pgsql-bugs by date

Next:From: nanda gopalDate: 2009-09-22 14:10:17
Subject: Requesting the Revision History
Previous:From: Amit KhandekarDate: 2009-09-22 12:16:58
Subject: BUG #5072: User trying to drop an internally dependent object crashes server

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