On Wed, Jan 27, 2010 at 12:08:48PM -0500, Tom Lane wrote: > Tim Bunce <tim.bu...@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.
Okay. I could change the callback code to ignore calls if proc_exit_inprogress is false. So an abnormal shutdown via exit() wouldn't involve plperl at all. (Alternatively I could use use on_proc_exit() instead of atexit() to register the callback.) Would that address this call sequence instability issue? > > 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. On Wed, Jan 27, 2010 at 09:53:44AM -0800, David E. Wheeler wrote: > Can you provide an example? Such concerns are impossible to address > without concrete examples. On Wed, Jan 27, 2010 at 01:08:56PM -0500, Tom Lane wrote: > Two examples that I can find in a quick review of our CVS history: perl > stomping on the process's setlocale state, and perl stomping on the > stdio state (Windows only). Neither of those relate to the actions of perl source code. To address that, instead of calling perl_destruct() to perform a complete destruction I could just execute END blocks and object destructors. That would avoid executing any system-level actions. Do you have any examples of how a user could write code in a plperl END block that would interact with the rest of the backend? Tim. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
