Re: Add on_perl_init and proper destruction to plperl [PATCH]
От | Tom Lane |
---|---|
Тема | Re: Add on_perl_init and proper destruction to plperl [PATCH] |
Дата | |
Msg-id | 8665.1264612128@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add on_perl_init and proper destruction to plperl [PATCH] (Tim Bunce <Tim.Bunce@pobox.com>) |
Ответы |
Re: Add on_perl_init and proper destruction to plperl [PATCH]
Re: Add on_perl_init and proper destruction to plperl [PATCH] |
Список | pgsql-hackers |
Tim Bunce <Tim.Bunce@pobox.com> writes: > On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote: >> (In particular note that shutdown itself might be fired as an atexit >> callback, a move forced on us by exactly the sort of random user code >> that you want to add more of. It's not clear whether a Perl-added >> atexit would fire before or after that.) > man atexit says "Functions so registered are called in reverse order". > Since the plperl atexit is called only when a plperl SP or DO is > executed it would fire before any atexit() registered during startup. Right, which means that it would occur either before or after on_proc_exit processing, depending on whether we got there through an exit() call or via the normal proc_exit sequence. That's just the kind of instability I don't want to have to debug. > The plperl subsystem is isolated from, and can't interact with, the rest > of the backend during shutdown. This is exactly the claim that I have zero confidence in. Quite frankly, the problem with Perl as an extension language is that Perl was never designed to be a subsystem: it feels free to mess around with the entire state of the process. We've been burnt multiple times by that even with the limited use we make of Perl now, and these proposed additions are going to make it a lot worse IMO. regards, tom lane
В списке pgsql-hackers по дате отправления: