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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: BUG #5066: plperl issues with perl_destruct() and END blocks
Дата
Msg-id 603c8f070909220637g16f58ca1l14d105b80e8711ae@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #5066: plperl issues with perl_destruct() and END blocks  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #5066: plperl issues with perl_destruct() and END blocks  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Amit Khandekar"
Дата:
Сообщение: BUG #5072: User trying to drop an internally dependent object crashes server
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5066: plperl issues with perl_destruct() and END blocks