From: | decibel <decibel(at)decibel(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [RFC] obtaining the function call stack |
Date: | 2009-07-13 20:51:58 |
Message-ID: | 785BA0E4-4C91-49DC-9E10-6EACEDCC638C@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2009-07-13 20:58:24 | Re: Predicate migration on complex self joins |
Previous Message | decibel | 2009-07-13 20:48:44 | Re: Predicate migration on complex self joins |