On Thu, Jan 28, 2010 at 10:39:33AM -0500, Tom Lane wrote:
> Tim Bunce 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 wou
Tim Bunce 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
>> gets called.
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 sugg
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
> Tim Bunce 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() in
On Wed, Jan 27, 2010 at 06:33:19PM -0500, Tom Lane wrote:
> Tim Bunce 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 coup
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 com
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 abl
"David E. Wheeler" 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 that the people w
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 (pgsql-hackers@postgre
"David E. Wheeler" 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 help to
>> sa
Tom Lane wrote:
"David E. Wheeler" 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
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
"David E. Wheeler" 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 pgFoundry an
"David E. Wheeler" 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
>> interac
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 fr
Tim Bunce 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 a
>> behav
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 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_proc_exit pleas
"David E. Wheeler" 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 do at any
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
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,
Da
On Wed, Jan 27, 2010 at 4:51 PM, David E. Wheeler 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 avoid executing
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 callba
On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
> Andrew Dunstan 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 tha
On Wed, Jan 27, 2010 at 12:08:48PM -0500, Tom Lane wrote:
> Tim Bunce 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
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-hacker
"David E. Wheeler" 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 with the
>> en
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
Tom Lane 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.
Is there a reas
Tim Bunce 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
>> at
f...@redhat.com (Frank Ch. Eigler) writes:
> Tom Lane 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
Andrew Dunstan 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 handle the case
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 shutdown
On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
> Tim Bunce 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 pa
Andrew Dunstan 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 major use case
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 t
Tim Bunce 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 atexit
callback, a
On Wed, Jan 27, 2010 at 01:14:16AM -0500, Tom Lane wrote:
> Andrew Dunstan 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 bloc
Tom Lane wrote:
Andrew Dunstan 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 the
On Wed, Jan 27, 2010 at 12:46:42AM -0700, Alex Hunsaker wrote:
> On Tue, Jan 26, 2010 at 23:14, Tom Lane wrote:
> > Andrew Dunstan 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.
> >>>
> >>> -
On Tue, Jan 26, 2010 at 23:14, Tom Lane wrote:
> Andrew Dunstan 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 r
Andrew Dunstan 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 DESTROY
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 fu
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, if
44 matches
Mail list logo
