Re: [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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)commandprompt(dot)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(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)decibel(dot)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(at)commandprompt(dot)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(at)themactionfaction(dot)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(at)commandprompt(dot)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