On Jul 13, 2009, at 4:51 PM, decibel wrote:
On Jul 13, 2009, at 2:33 PM, Tom Lane wrote:
Alvaro Herrera <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
