From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [RFC] obtaining the function call stack |
Date: | 2009-07-13 19:22:32 |
Message-ID: | 20090713192232.GI4930@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-07-13 19:26:53 | Re: [RFC] obtaining the function call stack |
Previous Message | Pavel Stehule | 2009-07-13 19:16:52 | Re: [RFC] obtaining the function call stack |