On Wed, Jan 27, 2010 at 06:33:19PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
Really? We've found that gprof, for instance, doesn't exactly have
zero interaction with the rest of the backend --- there's actually
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
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
Tim Bunce wrote:
I've no use-case for that so I'm happy to leave it disabled. If someone
does have a sane use-case, please let me know. It can always be enabled later.
As I noted upthread, there have been requests for user level session end
handlers before. With SPI enabled as Tom
Tim Bunce tim.bu...@pobox.com writes:
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
An advantage of on_proc_exit from your end is that it should allow
you to not have to try to prevent the END blocks from using SPI,
as that would still be perfectly functional when your callback
On Thu, Jan 28, 2010 at 10:39:33AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
An advantage of on_proc_exit from your end is that it should allow
you to not have to try to prevent the END blocks from using SPI,
as
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tim Bunce wrote:
- Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
SPI functions are not available when the code is run.
- Added normal interpreter destruction behaviour
END blocks, if any, are run then objects are
On Wed, Jan 27, 2010 at 01:14:16AM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tim Bunce wrote:
- Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
SPI functions are not available when the code is run.
- Added normal interpreter destruction behaviour
END
Tim Bunce tim.bu...@pobox.com writes:
On Wed, Jan 27, 2010 at 12:46:42AM -0700, Alex Hunsaker wrote:
FWIW the atexit scares me to.
In what way, specifically?
It runs too late, and too unpredictably, during the shutdown sequence.
(In particular note that shutdown itself might be fired as an
Tom Lane wrote:
Indeed, AFAICS the major *point* of these additions is to allow people
to insert unknown other functionality that is likely to interact
with the rest of the backend; a prospect that doesn't make me feel
better about it.
No. The major use case we've seen for END blocks is
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Indeed, AFAICS the major *point* of these additions is to allow people
to insert unknown other functionality that is likely to interact
with the rest of the backend; a prospect that doesn't make me feel
better about it.
No. The
On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
On Wed, Jan 27, 2010 at 12:46:42AM -0700, Alex Hunsaker wrote:
FWIW the atexit scares me to.
In what way, specifically?
It runs too late, and too unpredictably, during the shutdown sequence.
Tom Lane wrote:
But in any case, I don't believe for a moment that profiling is the only
or even the largest use to which people would try to put this.
Well, ISTR there have been requests over the years for event handlers
for (among other things) session
Andrew Dunstan and...@dunslane.net writes:
I see I asked the wrong question. Start again.
What more should be done to make all or some of it acceptable?
I think a must is to get rid of the use of atexit(). Possibly an
on_proc_exit callback could be used instead, although I'm not sure how
you'd
f...@redhat.com (Frank Ch. Eigler) writes:
Tom Lane t...@sss.pgh.pa.us writes:
Lastly, an atexit trigger will still fire during FATAL or PANIC aborts,
which scares me even more. When the house is already afire, it's
not prudent to politely let user-written perl code do whatever it wants
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
Tom Lane t...@sss.pgh.pa.us writes:
[...]
Lastly, an atexit trigger will still fire during FATAL or PANIC aborts,
which scares me even more. When the house is already afire, it's
not prudent to politely let user-written perl code do whatever it wants
before you get the heck out of there.
On Jan 27, 2010, at 9:08 AM, Tom Lane wrote:
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
David E. Wheeler da...@kineticode.com writes:
On Jan 27, 2010, at 9:08 AM, Tom Lane wrote:
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
On Jan 27, 2010, at 10:08 AM, 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).
Are there links to those commits?
Thanks,
David
--
Sent via pgsql-hackers
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
On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Indeed, AFAICS the major *point* of these additions is to allow people
to insert unknown other functionality that is likely to interact
with the rest of the backend; a
On Jan 27, 2010, at 1:27 PM, Tim Bunce wrote:
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
On Wed, Jan 27, 2010 at 4:51 PM, David E. Wheeler da...@kineticode.com wrote:
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
On Jan 27, 2010, at 1:53 PM, Robert Haas wrote:
What exactly do we mean by system-level actions? I mean, END blocks
can execute arbitrary code
Yeah. In Perl. What part of Perl can access the backend systems without SPI?
And that it couldn't do at any other point in runtime?
Best,
David
On Wed, Jan 27, 2010 at 01:51:47PM -0800, David E. Wheeler wrote:
On Jan 27, 2010, at 1:27 PM, Tim Bunce wrote:
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
David E. Wheeler da...@kineticode.com writes:
On Jan 27, 2010, at 1:53 PM, Robert Haas wrote:
What exactly do we mean by system-level actions? I mean, END blocks
can execute arbitrary code
Yeah. In Perl. What part of Perl can access the backend systems without SPI?
And that it couldn't
Tim Bunce tim.bu...@pobox.com writes:
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.)
Use
On Jan 27, 2010, at 3:11 PM, Tom Lane wrote:
You still aren't letting go of the notion that Perl could only affect
the rest of the backend via SPI. The point I'm trying to impress on you
is that there are any number of other possible pathways, and that Perl's
historical assumption that it
Tim Bunce tim.bu...@pobox.com writes:
On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
Really? We've found that gprof, for instance, doesn't exactly have
zero interaction with the rest of the backend --- there's actually
a couple of different bits in there to help it along, including
On Jan 27, 2010, at 3:33 PM, Tom Lane wrote:
I don't have to read any further than the place where it says doesn't
work if you call both plperl and plperlu to realize that that's quite
false. Maybe we have different definitions of what a software
interaction is...
I think that dates from
David E. Wheeler da...@kineticode.com writes:
On Jan 27, 2010, at 3:33 PM, Tom Lane wrote:
I don't have to read any further than the place where it says doesn't
work if you call both plperl and plperlu to realize that that's quite
false. Maybe we have different definitions of what a software
David E. Wheeler da...@kineticode.com writes:
On Jan 27, 2010, at 3:11 PM, Tom Lane wrote:
... Anything that Perl does to libc
state, open file handles, etc etc carries a high risk of breaking the
backend.
As could any other code that executes then, including C libraries installed
from
On Jan 27, 2010, at 4:10 PM, Tom Lane wrote:
Absolutely. The difference here is in who is going to be expected to
try to deal with any problems. When somebody says if I do this in
plperlu, my database crashes! Postgres sux! it's not going to help to
say that's a Perl bug, even if an
Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
On Jan 27, 2010, at 3:33 PM, Tom Lane wrote:
I don't have to read any further than the place where it says doesn't
work if you call both plperl and plperlu to realize that that's quite
false. Maybe we have different
David E. Wheeler da...@kineticode.com writes:
On Jan 27, 2010, at 4:10 PM, Tom Lane wrote:
Absolutely. The difference here is in who is going to be expected to
try to deal with any problems. When somebody says if I do this in
plperlu, my database crashes! Postgres sux! it's not going to
On Jan 27, 2010, at 4:15 PM, Tom Lane wrote:
Is that not the case with plperlu already?
Sure. Which is why I'm resisting expanding our exposure to it
I don't understand how it's expanding core's exposure to it.
Best,
David
--
Sent via pgsql-hackers mailing list
David E. Wheeler da...@kineticode.com writes:
On Jan 27, 2010, at 4:15 PM, Tom Lane wrote:
Sure. Which is why I'm resisting expanding our exposure to it
I don't understand how it's expanding core's exposure to it.
[ shrug...] I see little point in repeating myself yet again.
It's obvious
On Jan 27, 2010, at 4:33 PM, Tom Lane wrote:
[ shrug...] I see little point in repeating myself yet again.
It's obvious that the people who want this are entirely willing
to adopt a Pollyanna-ishly optimistic view about its potential
to cause serious problems that we may or may not be able
Tom Lane wrote:
It's obvious that the people who want this are entirely willing
to adopt a Pollyanna-ishly optimistic view about its potential
to cause serious problems that we may or may not be able to fix.
I don't really expect to be able to prevent something along this line
from getting
Tim Bunce wrote:
- Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
SPI functions are not available when the code is run.
- Added normal interpreter destruction behaviour
END blocks, if any, are run then objects are
destroyed, calling their DESTROY methods, if any.
SPI
Andrew Dunstan and...@dunslane.net writes:
Tim Bunce wrote:
- Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
SPI functions are not available when the code is run.
- Added normal interpreter destruction behaviour
END blocks, if any, are run then objects are
destroyed, calling their
This is the third of the patches to be split out from the former 'plperl
feature patch 1'.
Changes in this patch:
- Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
SPI functions are not available when the code is run.
- Added normal interpreter destruction behaviour
END blocks,
42 matches
Mail list logo
