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
|
Список | 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 по дате отправления: