Обсуждение: [RFC] obtaining the function call stack
Hi, This is a preliminary request for comments on obtaining a function call stack. I've been trying to dodge the issue by exporting elog.c internal state (errcontext), but that turns out to be unfeasible and it's such a horrid kludge anyway. So, the idea is to have a stack maintained by the function manager; each called function enters an element in it containing the interesting information about the function. We'd have another function that would return this stack as a result set. (With this arrangement, the topmost element would always appear to be this "peek" function.) I haven't looked at the code to see how this would actually be implemented, so I don't have more details to offer. Does anybody have opinions on the matter? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> So, the idea is to have a stack maintained by the function manager; each
> called function enters an element in it containing the interesting
> information about the function. We'd have another function that would
> return this stack as a result set. (With this arrangement, the topmost
> element would always appear to be this "peek" function.)
> I haven't looked at the code to see how this would actually be
> implemented, so I don't have more details to offer. Does anybody have
> opinions on the matter?
The performance and error recovery implications are unfavorable.
Just how badly do you need this, and for what?
regards, tom lane
Hello I did some similar (but Oracle like) in orafce - so it can help. I thing, so this should be very useful, but result set isn't best format. Usually you would to print to log and you have to iterate via set. So maybe better format could be some structured text. regards Pavel Stehule 2009/7/13 Alvaro Herrera <alvherre@commandprompt.com>: > Hi, > > This is a preliminary request for comments on obtaining a function call > stack. I've been trying to dodge the issue by exporting elog.c internal > state (errcontext), but that turns out to be unfeasible and it's such a > horrid kludge anyway. > > So, the idea is to have a stack maintained by the function manager; each > called function enters an element in it containing the interesting > information about the function. We'd have another function that would > return this stack as a result set. (With this arrangement, the topmost > element would always appear to be this "peek" function.) > > I haven't looked at the code to see how this would actually be > implemented, so I don't have more details to offer. Does anybody have > opinions on the matter? > > -- > Alvaro Herrera http://www.CommandPrompt.com/ > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > So, the idea is to have a stack maintained by the function manager; each > > called function enters an element in it containing the interesting > > information about the function. We'd have another function that would > > return this stack as a result set. (With this arrangement, the topmost > > element would always appear to be this "peek" function.) > > > I haven't looked at the code to see how this would actually be > > implemented, so I don't have more details to offer. Does anybody have > > opinions on the matter? > > The performance and error recovery implications are unfavorable. > Just how badly do you need this, and for what? Mainly for debugging. The situation is such that there is a lot of functions and very high load. The functions have embedded "debug elogs" and the intention is to call them only if the function was called in a particular context. I think error recovery would just have to be done carefully. As for performance, maybe the feature could be turned on with a (ugh) GUC variable, and defaults to off. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Pavel Stehule escribió: > Hello > > I did some similar (but Oracle like) in orafce - so it can help. I > thing, so this should be very useful, but result set isn't best > format. Usually you would to print to log and you have to iterate via > set. So maybe better format could be some structured text. Thanks. What's the file/function? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Jul 13, 2009, at 2:02 PM, Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> So, the idea is to have a stack maintained by the function >> manager; each >> called function enters an element in it containing the interesting >> information about the function. We'd have another function that >> would >> return this stack as a result set. (With this arrangement, the >> topmost >> element would always appear to be this "peek" function.) > >> I haven't looked at the code to see how this would actually be >> implemented, so I don't have more details to offer. Does anybody >> have >> opinions on the matter? > > The performance and error recovery implications are unfavorable. > Just how badly do you need this, and for what? The immediate goal is to be able to control debug output based on what function you're in, so that you don't get swampped by tons of debug output if you do SET client_min_messages = debug. (This is assuming you tend to write functions that have a bunch of RAISE DEBUG in them). In this case, all we'd care about is the function that called us. There are other times when I've wanted to know what function I'm actually in, though I think that's almost always been because RAISE DEBUG doesn't provide that context. So, if it makes it easier, we could probably get by with just the function that called us. Another possible option would be if there was a way to get our function name (which we could then pass on to the debug output function). -- Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> The performance and error recovery implications are unfavorable.
>> Just how badly do you need this, and for what?
> Mainly for debugging. The situation is such that there is a lot of
> functions and very high load. The functions have embedded "debug elogs"
> and the intention is to call them only if the function was called in a
> particular context.
I can't really see that as sufficiently widely useful to justify
inserting such a mechanism.
I suspect also that you are defining the problem the wrong way --- this
user doesn't want a generic fmgr call stack, he wants a plpgsql stack.
Which is something the plpgsql debugger could be taught to do, if it
doesn't already, thus avoiding the overhead the 99.9% of the time that
you don't need it.
regards, tom lane
2009/7/13 Alvaro Herrera <alvherre@commandprompt.com>: > Pavel Stehule escribió: >> Hello >> >> I did some similar (but Oracle like) in orafce - so it can help. I >> thing, so this should be very useful, but result set isn't best >> format. Usually you would to print to log and you have to iterate via >> set. So maybe better format could be some structured text. > > Thanks. What's the file/function? http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/orafce/orafce/utility.c?rev=1.9&content-type=text/x-cvsweb-markup Pavel > > -- > Alvaro Herrera http://www.CommandPrompt.com/ > PostgreSQL Replication, Consulting, Custom Development, 24x7 support >
Alvaro Herrera wrote: > This is a preliminary request for comments on obtaining a function call > stack. I've been trying to dodge the issue by exporting elog.c internal > state (errcontext), but that turns out to be unfeasible and it's such a > horrid kludge anyway. > > So, the idea is to have a stack maintained by the function manager; each > called function enters an element in it containing the interesting > information about the function. We'd have another function that would > return this stack as a result set. (With this arrangement, the topmost > element would always appear to be this "peek" function.) > > I haven't looked at the code to see how this would actually be > implemented, so I don't have more details to offer. Does anybody have > opinions on the matter? FWIW, pldebugger obtains a function call stack by peeking into the error context stack. It only includes PLpgSQL functions, and it's ugly and hacky. Something cleaner would simplify pldebugger, although it's always going to be hacky since it needs to understand quite a lot about PLpgSQL internal structures to display variables and stuff. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Jul 13, 2009, at 2:33 PM, Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> Tom Lane wrote: >>> The performance and error recovery implications are unfavorable. >>> Just how badly do you need this, and for what? > >> Mainly for debugging. The situation is such that there is a lot of >> functions and very high load. The functions have embedded "debug >> elogs" >> and the intention is to call them only if the function was called >> in a >> particular context. > > I can't really see that as sufficiently widely useful to justify > inserting such a mechanism. > > I suspect also that you are defining the problem the wrong way --- > this > user doesn't want a generic fmgr call stack, he wants a plpgsql stack. > Which is something the plpgsql debugger could be taught to do, if it > doesn't already, thus avoiding the overhead the 99.9% of the time that > you don't need it. Actually, this could conceivably be called from other languages, such as plPerl. But it sounds like this can be done via an add-on, so no need to add it directly to the backend. -- Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
On Jul 13, 2009, at 4:51 PM, decibel wrote: > On Jul 13, 2009, at 2:33 PM, Tom Lane wrote: >> Alvaro Herrera <alvherre@commandprompt.com> writes: >>> Tom Lane wrote: >>>> The performance and error recovery implications are unfavorable. >>>> Just how badly do you need this, and for what? >> >>> Mainly for debugging. The situation is such that there is a lot of >>> functions and very high load. The functions have embedded "debug >>> elogs" >>> and the intention is to call them only if the function was called >>> in a >>> particular context. >> >> I can't really see that as sufficiently widely useful to justify >> inserting such a mechanism. >> >> I suspect also that you are defining the problem the wrong way --- >> this >> user doesn't want a generic fmgr call stack, he wants a plpgsql >> stack. >> Which is something the plpgsql debugger could be taught to do, if it >> doesn't already, thus avoiding the overhead the 99.9% of the time >> that >> you don't need it. > > Actually, this could conceivably be called from other languages, > such as plPerl. > > But it sounds like this can be done via an add-on, so no need to add > it directly to the backend. How would I go about generating a meaningful backtrace for a plpgsql function that calls a plperl function? One would also expect a C function which calls a plpgsql function to appear, too, no? Shouldn't there be a unified backtrace subsystem? Cheers, M
On Mon, Jul 13, 2009 at 4:00 PM, A.M.<agentm@themactionfaction.com> wrote: > > How would I go about generating a meaningful backtrace for a plpgsql > function that calls a plperl function? One would also expect a C function > which calls a plpgsql function to appear, too, no? Shouldn't there be a > unified backtrace subsystem? > i guess, that is what Alvaro is suggesting -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157
Pavel Stehule escribió: > 2009/7/13 Alvaro Herrera <alvherre@commandprompt.com>: > > Pavel Stehule escribió: > >> Hello > >> > >> I did some similar (but Oracle like) in orafce - so it can help. I > >> thing, so this should be very useful, but result set isn't best > >> format. Usually you would to print to log and you have to iterate via > >> set. So maybe better format could be some structured text. > > > > Thanks. What's the file/function? > > http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/orafce/orafce/utility.c?rev=1.9&content-type=text/x-cvsweb-markup Thanks. I played with this for a couple of hours, and the inevitable conclusion is that this approach is doomed, if only because it depends on the user not setting a non-english locale. Otherwise errcontext() would store translated messages in the error stack, and the code trying to parse them would fail miserably. I haven't looked at pldebugger, but if it does anything similar to this, it's obviously prey to the same problem ... which I guess means that we really need some more robust way of doing it, there already being three potential users of it. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support